simply put, i think that the input 'size' field is now obsolete (like the rest of html styling outside of css), and most of the sizing attributes have been deprecated, so why not input.size?
Maybe you got confused between size and width/height attributes (btw I got confused at first when you said field). But assuming you didn't, let me explain what size is for.
size attribute
The attribute size for element <input> applies to text inputs, like e-mail, password, etc. It defines the maximum character width for the input. Let's say for example you want the maximum password length to be 4 to screw the users, you give it size=4, so you cannot enter passwords like dinosaur (anything you type after dino will not appear unless you delete the previous letters first)
Edit: as pointed out by Maksym in the comments, the above is defined by maxwidth, not size. size is, if we refer to HTML4 spec,
except when type attribute has the value "text" or "password". In that case, its value refers to the (integer) number of characters.
So size=4 is about 4 (monospaced?) characters wide (My experiment with Google Chrome has makes it size+1 though, i.e. size=4 is 5 characters wide.)
Dimension attributes
Now in case of the dimension attributes width and height. For <input> elements, they apply only to image buttons. They define the dimensions of the button. Now why can't you just apply CSS to them?
First, know that CSS is for visual purposes. Image buttons submit coordinates that the user clicked on. This behavior needs to be consistent across browsers, whether they support CSS or not. See this warped image:
There may be a case where the user is asked to click the letter e for the form submit to be processed differently. Probably the server will check whether the x coordinate is 75 <= x <= 90. But if you defined the dimension with CSS, browsers which disabled CSS will see this image instead:
And the previous coordinate range check is no longer valid, seeing that the letter e is further to the right, hardly within 75 and 90 (and you need to click on the left side of the first o to get the same input).
That is a rhetorical question really... or an attempt at persuasive argument. You are right, though-- it could easily be deprecated and CSS take over. As for why, that answer can only come from someone inside W3C who is part of the decision making process. You could also ask why cellpadding, cellspacing, and width properties are not deprecated in tables.
The best answer I can give you to your non-question is that HTML isn't a purist language--while it's getting back to it's roots of being just content and not style or behavior, it still has it's legacy from the 90's and 00's, which means it still has concerns beyond just content.
There's a valid reason why this attribute isn't deprecated: "Web Usability"
When a user views your site, considering the CSS is turned of or unavailable, it's really a bad idea to let the person see a long field while in fact, the field only requires a few characters (such as ids, phone numbers, etc.).
CSS is good, yes, but only if you also considered people who won't be able to use them.
Related
I am using jQuery and I am just wondering, does ID have to be always unique in the whole page? Class, I know, can be repeated as many times as you like, what about ID?
Yes, it must be unique.
HTML4:
https://www.w3.org/TR/html4/struct/global.html#h-7.5.2
Section 7.5.2:
id = name [CS]
This attribute assigns a name to an element. This name must be unique in a document.
HTML5:
https://www.w3.org/TR/html5/dom.html#element-attrdef-global-id
The id attribute specifies its element's unique identifier (ID). The
value must be unique amongst all the IDs in the element's home subtree
and must contain at least one character. The value must not contain
any space characters.
Does an ID have to be unique in the whole page?
No.
Because the HTML Living Standard of March 15, 2022, clearly states:
The class, id, and slot attributes may be specified on all HTML elements. …….
When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element’s tree and must contain at least one character. The value must not contain any ASCII whitespace.
and a page may have several DOM trees. It does, for example, when you’ve attached (Element.attachShadow()) a shadow DOM tree to an element.
TL; DR
Does an ID have to be unique in the whole page?
No.
Does an ID have to be unique in a DOM tree?
Yes.
from mdn
https://developer.mozilla.org/en/DOM/element.id
so i guess it better be...
Technically, by HTML5 standards ID must be unique on the page - https://developer.mozilla.org/en/DOM/element.id
But I've worked on extremely modular websites, where this is completely ignored and it works. And it makes sense - the most surprising part.
We call it "componentization"
For example, you might have a component on your page, which is some kind of widget. It has stuff inside with their own unique IDs eg "ok-button"
Once there are many of these widgets on the page, you technically have invalid HTML. But it makes perfect sense to componentize your widgets so that they each, internally, reference their own ok button eg if using jquery to search from it's own root it might be: $widgetRoot.find("#ok-button")
This works for us, though technically IDs shouldn't be used at all, once they're not unique.
As cited above, even YouTube does it, so it's not so renegade.
Jan 2018, here is Youtube HTML , you can see id="button" id="info" are duplicated.
That's basically the whole point of an ID. :) IDs are specific, can only be used once per page. Classes can be used as pleased.
Browsers used to be lenient on this (many years ago when css was young) and allow the ID to be used more than once. They have become more strict.
However, yes ID's are to be unique and only used once.
If you need to use css formatting more than once use CLASS.
With Javascript, you can only reference to one element using ID. document.getElementById and jQuery's $ selector will return only the first element matching. So it doesn't make sense using the same ID on multiple elements.
There are great answers for the same question at https://softwareengineering.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really.
One tidbit not mentioned above is that if there are several identical ids one the same page (which happens, even though it violates the standard):
If you have to work around this (that's sad), you can use $("*#foo") which will convince jQuery to use getElementsByTagName and return a list of all matched elements.
Yes, IDs are unique. Class are not.
IDs always have to be unique.
Everybody has a unique identification number (ex. Social Security number), and there are lots of people in a social class
I'm adding to this question, because I feel it has not been answered adequately in any of the above,
As a point reference: I've implemented non-unique id's, and all works just fine (across all browsers). Importantly, when coding, I've not run into any css logic errors, which is where the rubber hits the road (IMO) on this question. Have also not run into any conflicts in js (as one can glean out id's in context with classes)
So, why do id's have to be unique? Obvious answer (as stated and re-stated above) is 'cause the 'standards' say so. The missing part for me is why?
i.e. what actually goes awry (or could theoretically go awry) if (heaven forbid) someone inadvertently used the same id twice?
The reference with all browsers these days?
Makes div possible in such terms of being used multiple times.
There is no rule that it must be unique. When all browsers understand:
<script>div#some {font-size: 20px}</script>
<div id="some"><p>understand</p></div>
<div id="some"><h1>me too</h1></div>
When you add new style CSS codes you have the possibility to use the addition of styles. Since that even is not supposed to be unique it describes the opposite use, so make more styles but do not make more objects? And as you can; assign several div objects, so why didn't they tell you that class must be unique? That's because the class does not need unique value. And that makes the ID in legal terms obsolete if not being unique.
<script>.some {font-size: 25px}</script>
<div class="some"><p>enter</p></div>
<div class="some"><h1>enter</p></div>
"When there is no rule when a rule is said. Then the rule is not fulfilled. It's not inherent to exist. By only in the illusion of all rules that it should have existed only to make life much harder."
Just because some people say div must be unique, this might be right, but at least through their professional perspective to say it, they have to say it. Unless they didn't check the modern browsers, which from nearly the beginning were able to understand the code of several different div objects with the same style.
ID must be unique - One reason for that is, that in the Browser-JavaScript-Context exists a methode: Document.getElementById()
This method can only return one element.
If a Document has not unique IDs, this function behaves in an undocumented and unforeseeable way.
I think, this is reason enough to only use one ID per Document.
Reference:
https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById
What is the best practice for making information normally displayed as the background color of a cell accessible (for screen readers and such)?
This is an example of my table (with names and numbers changed to protect the innocent):
The table contains temperatures. Yellow and red backgrounds indicate the results of screenings. My real table is very large and making it information-dense is a high priority, so I don't want to just put the results of the screening in the cell as text as it would make my columns much wider. Ideally, I would put an alt-text of some sort on the yellow and red cells with something like "positive test result" or "failed screening". Is there a way to do this in an HTML table?
I thought maybe title would be the right attribute here, but the internet says that is wrong.
Short answer
If the color brings a real information, like telling if it succeeded (green) or failed (red), the best is to write it plain text next to the value.
Alternatively, you can use an icon with proper markup.
Longer answer
The general rule as stated in WCAG is don't convey information only with colors, basicly meaning
you must add something else other than just colors to allow everyone to get the information.
You can add anything you like, i.e. text or icon. It's fine as long as there is another way than just color to get the information.
You may be tempted to write the information in plain text but make it visible only for screen reader users, as follows:
<td>123<span class="sr_only"> Success</span></td>
<td>-45<span class="sr_only">Failed</span></td>
Or alternatively, use aria-label with these additional warnings:
aria-label is guaranteed to be taken into account only if the element is interactive. By default a table cell isn't interactive.
The aria-label attribute entirely replaces the content of the cell. So you must write <td aria-label="123, success">123</td> and not <td aria-label="success">123</td> because in that later case the screen reader user won't get the value.
However, both are in fact bad ideas, and don't fully conform to the WCAG rule stated above.
For example, color blind people can see the screen and so don't need a screen reader, but may not be able to make the difference between red and green.
Thus the data wouldn't be accessible to them.
The fixed scale case
IF your colors express some scale, i.e. green is good, yellow is acceptable and red is bad, and if the color depends on fixed values, i.e. green above 60, yellow between 40 and 60 and red below 40, then in fact the color doesn't bring any new information.
It is just a visual indication so that you can quickly see what is good and what is bad. IF you remove the colors, you certainly lose some ease, but the information is still there in the value itself.
IN this case, it can quickly become uselessly noisy to add a text saying "good", "acceptable" or "bad" in each cell,
since as long as you remember the scale, the value itself tells you if it's good or bad.
OF course you will explain clearly and in plain text the meaning of the colors, probably above or below the table, and make the information visible for all users.
This is my code:
<table>...Some content...</table>
<table>...Another content...</table>
I want to put the second table on top of the first table. This is to be used as an email template (in some clients position and margin are not available).
Those are the only two options available (outside of transform, which definitely won't work if position isn't available) that will allow one element to invade another element's space. If you can't use position or margin, then you're out of luck, and you need to re-evaluate what you are trying to achieve and why. Any chance you could do this with images?
There are always ways...not always elegant, but when you have limited options, 'works' is often all you really need. IMO, creativity is as much about solving a problem with limited options as it is thinking 'outside the box'.
Most email clients allow you to set 'height', so simply wrap the first table (the background) in a div and give that div height:0px;. the table will overflow the div, but the next element won't respect it's space because it has 0 height, and will effectively be layered in front.
http://jsfiddle.net/L0d3tnzu/
If you want the size of the tables to match exactly, you'll probably have to explicitly set heights and widths, but the fiddle above illustrates the basic concept. Hope this helps!
EDIT:
Based on the additional info in the comment (the second table should only partly overlap the first table) here is an updated fiddle: https://jsfiddle.net/acq3ob6y/1/
EDIT #2:
Dang. Outlook switching to the Word/Office rendering engine for HTML/CSS might be the only way possible to get WORSE than the IE version. Sigh. (Thanks to #Gortonington for the comment/clarification, though!)
Ok, then, the idea of a background image is only a problem for retina displays (if you want them to be all crisp and beautiful and retina-ie), and retina devices are going to be handling CSS in a more modern way (hopefully!), so how about this as a solution: Media Query targeting device resolution loads CSS with the double-size img and uses css background-size to constrain it: http://jsfiddle.net/tcyjo7ok
Third try is a charm? At least the list of options is growing...
The only way to overlay two elements across email clients is through use of background images. Even this can be broken in some clients and requires a lot of conditional and reiterate code (backgrounds.cm is good resource for email bg images).
This is the only option that will display in MOST clients. Even this is still very restricted and not very agile to use (but that is true in ALL email coding). Most other techniques will only work for a couple clients and break completely in all others.
In HTML forms input fields and their captions are declared as label and input tags, but which tags should be used for displaying the same data?
I'm considering either dl, dt, dd or label and disabled input tags, but both solutions don't feel right.
Of course there are many ways to "somehow" display the data, but I was wondering if there's a preferred way to do this.
Bear in mind that label/input is just a user-adjustable variation of the notion of key/value (or name/value) pairs. What you want is merely something that represents a key (label) and value (text) in such a way that the two can be distinguished from each other. The input performs the "value" function visually, and forces the user to regard the label as the name of the value. Without the visual clue of the input you can still make the name/value relationship obvious by bolding the name, putting it in a different color, different font, spacing, etc.
Even if you were to use <dd> and <dt> and the like, you would still need to make sure the name/value distinction was visually distinctive. (Especially if you were using a reset stylesheet that canceled out any inherent browser-generated difference between the tags.)
I think this depends on what the data is and how you'd describe it.
If you're showing a list of titles with associated reference data then a definition list seems to fit the bill. (Since it retains the semantic link between title and reference data).
This will be similar in how the label is directly linked to your form fields using the for attribute, making it not just about visual reference but also about data connection and relation.
I usually ask myself the question, "What am I trying to say here?" and "How do my data relate to one another".
I have a set of HTML codes and I am wondering how can I wrap a code such that it is interpreted correct by the browser and independent of the others.
I think I should give an example:
x = <a href="stackoverflow.com">Something
y = <b>Else</b>
I print x, then y and the browser will consider that y is part of the link defined in x. How can I force the browser to interpret x independent of y; that's is, how can I wrap x and y?
I don't know if it is relevant, but I work in Python.
Thanks!
Close the anchor tag if you don't want the bold tag to be part of it.
x = Something
If you don't close the anchor, most browser will assume that the rest of the document is contained within this tag.
Also, could I recommend that you use <strong> instead of <b> since <b> is not semantic.
Modern browsers do a good job of "cleaning up" broken or invalid HTML code. Obviously though there are lots of situations where what the author intends is not what the browser interprets. Your example is a good one: where should the browser insert the closing </a> tag? The browser has internally a bunch of rules to decide where to do this (which in your case doesn't give you what you want).
The only way to reliably get a browser to render exactly want you want is to ensure that what you are sending to the browser is correct! In that case, look at your HTML strings independently and add missing end tags where needed.
(Depending on the complexity of the HTML, there's possibly a number of approaches to this. You might be able to get away with manually checking each string, or if the HTML is more complex, you might need to use a parser.)
You must find all the tags in the HTML snippets and make sure that they are closed properly.
A simple solution is to use this regexp: r<[^>]+> and this pseudocode:
find next match:
if match ends with `/>`:
continue
if match starts with '</':
Pop element from stack and make sure that the name matches the element from the match
else:
Push element name on stack
for each element on stack:
print '</%s>' % element.name