[whatwg] The semantics of visual offsetting vs. verbal offsetting
My understanding of the semantics of and vs. and is that the former indicate a stress, emphasis, offset or importance that would be expressed verbally, if reading aloud. On the other hand, the and tags indicate stress, emphasis, offset or importance that is visual or typographic. I frequently see people arguing that is the most semantic element to use for a term or keyword because it is the most "important," but in a situation where you would never change the way you read the sentence verbally, but rather, just want the typographic indication that it's a term. To me, I think this is coming from some ambiguity in the word "important" that causes people to fundamentally misunderstand when to use vs . Is my understanding (i.e., thinking in terms of visual vs. verbal offset as a way of clarifying the meaning of the definitions) right here, and if so, is there some sort of less ambiguous, authoritative document that I can point people to when these discussions come up? Semantics conversations always seem to come back to a fundamental disagreement about the meaning of the words used in the W3C specification.
[whatwg] What's the element for a paragraph label?
For example: Tip: You should always use the most semantic element! Oops, is for inputs, so that's not right! Should I use a heading? Doesn't seem right either. Is this a case for ? The specification doesn't mention labels under the definition. Is there a semantic element that can be used in a situation like this? If so, I propose adding "label" to the specification for that element. Then again, maybe this most appropriately a . Cheers!
[whatwg] Controlling the UI on
It is currently difficult to control the visibility of the UI (e.g. little arrows, spinners, etc) on new input types like datetime, number, range, color, etc. It seems that many developers want to use the semantic attributes, but need to be able to hide the little arrows for various reasons, and so they are sticking with type=text (e.g. http://stackoverflow.com/q/11418289/925897 ). Reasons developers might want to control the visibility of the UI: - developer has built their own datepicker/numberfinder/colorpicker/etc - developer wants to display just the values (as if it were type=text) upon printing, or when readonly, or when not active As browsers add support, there will likely be ways to control this using vendor-specific CSS, but not only will this vary from browser to browser, it will vary among the different input types. For example, in Chrome it is currently possible to hide the slider arrows on the number input: input[type="number"]::-webkit-inner-spin-button{ -webkit-appearance: none; } This kind of code is clearly going to be very difficult to maintain and keep up to date. I don't think a CSS solution is going to work. Has there been discussion here on an input attribute that controls the UI? Perhaps something like this:
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, May 16, 2012 at 12:13 AM, Tab Atkins Jr. wrote: > > I've been doing a lot of work today correcting misconceptions about > the Responsive Images proposal that Hixie put into the spec today. I > was pretty astonished at how much misinformation was flying around; > what's worse, this sort of misinformation was actually making people > *angry*, which doesn't exactly make people willing to calmly listen to > corrections. So, hopefully this email finds everyone in calmer moods, > so we can get everyone on the same page. > Any others that people can think of? I have a question regarding Tim Kadlec's summary of the order of events in all of this [1]: > 1. Developers got involved in trying to standardize a solution to a > common and important problem. > 2. The WHATWG told them to move the discussion to a community > group. > 3. The discussion was moved (back in February), a general consenus > (not unanimous, but a majority) was reached about the picture element. > 4. Another (partial) solution was proposed directly on the WHATWG > list by an Apple employee. > 5. A discussion ensued regarding the two methods, where they > overlapped, and how the general opinions of each. The majority of > developers favored the picture element and the majority of implementors > favored the srcset attribute. > 6. While the discussion was still taking place, and only 5 days after it > was originally proposed, the srcset attribute (but not the picture element) > was added to the draft. His account has been quoted [2] elsewhere, and while Tim's order of events seems mostly accurate, Jeremy Keith has clarified [3] that the WHATWG never suggested a CG be created and that Ted's 'srcset' solution wasn't as completely out of the blue as it seemed. However, it still looks like the most upsetting implication of his timeline, namely that the WHATWG is prioritizing implementors over authors, remains unclarified. Is it a misconception to say that the levels of priority outlined in the W3C HTML design principles [4] are not being followed here? Especially since it seems that we can extend Tim's timeline with: 7. Authors react negatively to the addition of 'srcset' in the draft. 8. The 'living' draft is not changed and the authors' anger eventually fades into hopeless acceptance because once something goes in to the draft, it is set in stone forever and for all time. Ok, so 8 is both hyperbolic and in the future, but a lot of people seem to think that this is where we are headed. Personally, I'm not angry about this and I'm willing to calmly listen to corrections, I'm just trying to wade through all the misinformation here. -Brenton Strine [1] http://timkadlec.com/2012/05/wtfwg/ [2] http://adactio.com/journal/5474/ [3] http://www.goodreads.com/author_blog_posts/2463167-secret-src [4] http://www.w3.org/TR/html-design-principles/
[whatwg] Why isn't the "pattern" attribute applied to ?
Regarding the an input with type in the "number" state, the spec states that the "pattern" attribute "must not be specified and do[es] not apply<http://dev.w3.org/html5/spec/common-input-element-attributes.html#do-not-apply> to the element". ( http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number ) Why is it specifically blocked? Doesn't that encourage the use of a less semantic "text" input type for numbers that need to be validated beyond simple max and min? What if you want the number to be either 13 or 16 digits long, as with a credit card pattern="(\d{5}([\-]\d{4})?)" or you want a US ZIP or ZP4 code which can either be n or n- pattern="(\d{5}([\-]\d{4})?)" To get the pattern to validate, I have to (non-semantically) change the input to the text state? I much prefer the current behavior of Firefox (tested 9 and 10) which does validate the pattern. Brenton Strine
Re: [whatwg] required attribute in label
> and > are effective, but then again this would be too: ...* It just seems a shame that we have this neat attribute that indicates required controls, but we can't actually use it to change the presentation adding additional code. Brenton
Re: [whatwg] Footnotes
Maybe after having a few months to think about it some better ideas will pop up? I'd like to see a dedicated way to do footnotes as well. I think it would be worth having the discussion again. Brenton -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson Sent: Monday, December 15, 2008 2:11 PM To: Douglas Mayle Cc: wha...@whatwg.org Subject: Re: [whatwg] Footnotes On Mon, 15 Dec 2008, Douglas Mayle wrote: > > I'm sorry to bring this up if the subject has been touched on before... > > In perusing the HTML5 standard, I noticed that footnotes are still a > redheaded stepchild in the draft. Given how many workarounds and > hacks are performed to create support for footnotes using standard > elements, is there any reason why there isn't a dedicated mechanism > for footnotes in HTML? The main reason is that we couldn't find any solutions that were especially compelling. A more detailed response to the earlier feedback on the topic is here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-April/014485.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote: [snip] > 4) (moving label textual content into as placeholder text; > currently with Javascript to mutate the DOM, in the > future with CSS to > present the desired appearance while keeping the DOM stable) > Pro: Most semantic. [snip] That depends on what you are using it for. What if you are using it to apply a placeholder that says "(optional)"? That is not a label at all. There are a lot of uses for the proposed placeholder attribute that just don't fit into any of the other categories. I think a placeholder attribute would be great. Brenton Strine
[whatwg] HTML 5 will be ready in 2022
I know many web developers who get upset when they hear that HTML 5 is expected to become an official reccomendation in 2022. But as we all know, HTML 5 is already having real world effects and even being implemented in browsers. Is there some place that documents the parts of HTML 5 that are already up and running? Can I use or ? In which browsers? What other tags can I use? What other fancy HTML 5 stuff can I do today in 2008? Shouldn't the whatwg wiki document that kind of stuff? Brenton Strine
[whatwg]
By now, everyone has heard that IE8 'passes' the Acid2 test, but (To paraphrase Jeremy Keith: http://adactio.com/journal/1402/) won't render pages with the new standards-compatibility unless you explicitly tell it to with this meta tag: --i.e. it actually won't pass Acid2 because the test doesn't have that meta tag in it. I agree with Jeremy that this is a mistake. One of the reasons I write standards-compatible code is so that my websites will work in future browsers when they support new/better features. All such webpages are effectively locked into IE7 now, and won't get any benefits of the newer browsers unless I add this new meta tag. The example from the article is generated content. Since IE8 isn't out the door yet, I wonder if we can't do anything about this to prevent a bad situation for years to come. My thought is this (and I'm hoping other people will come up with better ideas). Give HTML the ability to declare specific technologies that it uses, such that if a browser supports that technology, it makes use of it. Sort of like using object detection in javascript instead of messing with the user agent string. For example, assume an amazing new image format comes out called AwesomeImg--Opera 11 supports it, but you're not sure when IE will. Maybe IE10. But you don't want to lock your site into IE10 mode because it might break in IE10, or IE10 might still not support all your features but IE11 would have. There should be a way to tell the browser it can implement your technology without locking your website into a specific version. A website can then avoid the use of the "edge" attribute, which might cause future breakage, but also would avoid being locked eternally in the limitations of a specific browser version, be it IE7, IE8, IE9, etc. If we get this into the spec soon enough, Microsoft might incorporate it in IE8 before it releases. What do you think? Whether it's a good idea or a bad idea, I feel that the whatwg needs to address this issue somehow. Brenton Strine
Re: [whatwg] additional empty elements
> HTML is a language for markup meaningful by itself, not just as a hook for CSS. > doesn't mean anything. That doesn't seem very practical to me. If all HTML tags imply some meaning, then you are advocating the elimination of presentation, not it's separation. If there weren't any CSS hooks, wouldn't people just (incorrectly) use other tags, like ? I think that CSS and HTML are unbreakably connected. Brenton
[whatwg] additional empty elements
I would like to know what other people think about creating more empty elements in HTML5. Say, for example, you have a website which has sections of content that are indented variously. It would be easy to accomplish the different styles using classes: This text isn't indented at all! This text is indented a little. Lots of indentation. No indentation here! However, if I then wanted to add additional special styling to the first and third div, (e.g.. a border and background color) it is less graceful. I could add style attributes, but that would be wasteful if I want to do this on a large scale. Multiple classes would be confusing. A nice solution would be the addition of a few div tags. (e.g. , , and .) Then you could do something like this: div1 {text-indent:0px;} div2 {text-indent:10px;} div3 {text-indent:20px;} Then: This text isn't indented at all! This text is indented a little. Lots of indentation. No indentation here! This is much more human-readable, and the addition of additional styles is now elegant and easy with the use of classes. This text isn't indented at all! This text is indented a little. Lots of indentation. No indentation here! I also think that it would simply be easier to write code if there were a few extra non-semantic empty tags. HTML5 needs improvements that will make people want to use it. Making it easier to code than HTML 4 will ensure a quicker and wider acceptance. I am okay with the unimaginative numbering of the extra elements, as it would make it easy to have a lot of new elements. However, there are countless possibilities: , , , , , , , , etc... Are there other people who have found themselves wishing for another or -like tag? Brenton Strine
Re: [whatwg] Suggestion for new element/attribute
Consider this case: You have a table one row high with two cells. It's width is 100%. You want the width of the left cell to be only as big as the content, and you want the right cell to take up all the rest of the space. However, the amount of content in both the right and the left cell changes, so you can't give a percent or a pixel width. In that situation, you could either 1) intentionally give the right cell an incorrect width of 100%, or 2) put a whole lot of invisible text in it, so that the cell always expands enough to make the left cell only the minimum size needed. -Original Message- From: Benjamin Hawkes-Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 3:44 PM To: Brenton Strine Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Suggestion for new element/attribute This sounds very much like something that should be done in CSS, not HTML. But can you explain what you mean by "expand ... as if it were full of text"? If something is already a given size, then filling it with text should not make it expand. -- Benjamin Hawkes-Lewis Brenton Strine wrote: > Hello, > > I am new here, so please let me know if I am doing > anything out of order. > > I would like to make a suggestion for soemthing I want to > see in HTML5. > > I call it the inflate tag. . > > The purpose of this tag is to expand that which contains > it as if it were full of text. I have seen many websites > where the designers were forced to put long strings of > hidden text into a cell in order to make it expand > correctly. Thus text browsers find strange segments like > this: > > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w w w w w w w w w w w w w w w w w w w w w w > w w w w w w w w > > Of course, developers already have the ability to specify > the width in terms of pixels, ems, percent, and tons of > other stuff. But there are times, particularly in fluid > design, when you can't get the div to work the way you > want without text to expand it. > > This could even be an attribute rather than a tag: > width="inflate". > > Brenton >
[whatwg] Suggestion for new element/attribute
Hello, I am new here, so please let me know if I am doing anything out of order. I would like to make a suggestion for soemthing I want to see in HTML5. I call it the inflate tag. . The purpose of this tag is to expand that which contains it as if it were full of text. I have seen many websites where the designers were forced to put long strings of hidden text into a cell in order to make it expand correctly. Thus text browsers find strange segments like this: w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w Of course, developers already have the ability to specify the width in terms of pixels, ems, percent, and tons of other stuff. But there are times, particularly in fluid design, when you can't get the div to work the way you want without text to expand it. This could even be an attribute rather than a tag: width="inflate". Brenton
Re: [whatwg] sarcasm
So why not use the q element for irony as well, since a quote already indicates both quotations and irony. On 4/24/07, Elliotte Harold <[EMAIL PROTECTED]> wrote: Alexey Feldgendler wrote: > In Western typography, there is already a tradition to mark up irony > with quotation marks: > > Yeah, George W. Bush has been such a "great" president. There's an even stronger tradition to mark quotes with quotation marks, and yet we have the q element. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/