Re: [whatwg] maincontent element spec updated and supporting data provided
On Wed, Oct 17, 2012 at 3:03 AM, Steve Faulkner
faulkner.st...@gmail.com wrote:
I have updated the maincontent spec [1] and would appreciate any feedback
(including, but not limited to implementers).
bikeshedA single-word element name would me more consistent with
other HTML element names. content would be rather generic, so I
think main would be the better option./bikeshed
It would probably make sense to add
main { display: block; }
to the UA stylesheet.
If Hixie had added this element in the same batch as section,
article and aside, he would have made the parsing algorithm
similarly sensitive to this element. However, I'm inclined to advise
against changes to the parsing algorithm at this stage (you have none;
I am mainly writing this for Hixie), since it would move us further
from a stable state for the parsing algorithm and, if the main
element is used in a conforming way, it won't have a p element
preceding it anyway.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Ian, Thanks for the detailed example, your reasoning is clear now and that give sme something to work with, and thanks for filing a bug! will respond on bug. regards SteveF On 18 October 2012 07:28, Ian Yang i...@invigoreight.com wrote: On Thu, Oct 18, 2012 at 1:31 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, Like the succinct and simple name of complementary content (aside), could we make the element name of the main content as succinct as aside? For instance, main? I have responded on the HTML WG list to a similar naming preference comment: http://lists.w3.org/Archives/Public/public-html/2012Oct/0112.html Thank you. Since the complementary content (aside) is a sectioning element, could we make the main content element a sectioning element, too? Can you provide some more reasoning for making the element sectioning content? There is a now W3C bugzilla component for the HTML5 maincontent extension, you can file bugs against the spec there to ensure that your comments get recorded and responded to: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WGcomponent=maincontent%20element regards SteveF Because both being elements for content, it is inconsistent that complementary content is sectioning element and main content is not. Another reason is about document outline. Please take a look at the markup below: !DOCTYPE html titleblablabla/title header h1Branding/h1 nav h1Navigation/h1 blablabla /nav aside h1Search/h1 blablabla /aside /header main role=main h1Main Content/h1 section h1Welcome/h1 blablabla /section section h1Brief Intro/h1 blablabla /section /main aside role=complementary h1Complementary Content/h1 article h1Latest News/h1 blablabla /article article h1Recent Comments/h1 blablabla /article /aside footer blablabla /footer If the main content element is a sectioning element, the document outline formed by the above code will be clear and hierarchically correct: 1. Branding 1. Navigation 2. Search 3. Main Content 1. Welcome 2. Brief Intro 4. Complementary Content 1. Latest News 2. Recent Comments But if the the main content element is not a sectioning element, the document outline will be confusing and hierarchically incorrect: 1. Branding 1. Navigation 2. Search 2. Main Content 1. Welcome 2. Brief Intro 3. Complementary Content 1. Latest News 2. Recent Comments Both main content and complementary content are content, so they are supposed to be at the same level in document outline. A bug report for this issue has been filed on bugzilla. Kind Regards, Ian Yang http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Steve, Thanks for your work, too :) Regards, Ian On Thu, Oct 18, 2012 at 2:14 PM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, Thanks for the detailed example, your reasoning is clear now and that gives me something to work with, and thanks for filing a bug! will respond on bug. regards SteveF
Re: [whatwg] Features for responsive Web design
Am Donnerstag, 18. Oktober 2012 um 04:05 schrieb Fred Andrews: This is good point. Could I just clarify my understanding with an example: Given a thumbnail image with srcset: srcset=low.jpg 20w, hi.jpg 40w, huge.jpg 80w The webpage may want to have the browser scale the 20w image to say 50px without the browser deciding that the 40w image is more appropriate? Perhaps it would be realistic for this case to simply not be supported. srcset cannot support this case. This is one case (of many) why we suggested picture-element. Authors have the alternative option of using an encoding with a lower quality to reduce the image file size, rather than supplying a low resolution image that the browser scales up. Perhaps when the file size is far more important than image quality a single image would suffice anyway. I don't think that is an answer for such a problem. It is how you would solve it today. Not how you want to solve it. Cheers -Anselm cheers Fred To: whatwg@lists.whatwg.org (mailto:whatwg@lists.whatwg.org) Date: Mon, 15 Oct 2012 18:40:21 +0200 From: odi...@opera.com (mailto:odi...@opera.com) Subject: Re: [whatwg] Features for responsive Web design On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst derer...@gmx.ch (mailto:derer...@gmx.ch) wrote: This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w What about an image gallery, when you have 25 thumbnails on one page? I'm not sure how this will work in cases where you don't want the image to be the max size your screen can handle. Even the common case of having an article picture that is not 100% of the screen width will be hard to do in a responsive non-fluid way with predefined breakpoints. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Encoding: API
I added the API to the Encoding Standard: http://encoding.spec.whatwg.org/#api Feedback welcome. I suppose we might want to write an introduction for it too. On Thu, Oct 11, 2012 at 6:37 PM, Joshua Bell jsb...@chromium.org wrote: It sounds like there are several desirable behaviors: 1. ignore BOM handling entirely (BOM would be present in output, or fatal) 2. if matching BOM, consume; otherwise, ignore (mismatching BOM would be present in output, or fatal) 3. switch encoding based on BOM (any of UTF-8, UTF-16LE, UTF-16BE) 4. switch encoding based on BOM if-and-only-if UTF-16 explicitly specified, and only to one of the UTF-16 variants I went with supporting just 2 for now. 4 seems weird. The behavior of the normal decode algorithm does not need to be exposed through the API I think, unless a use case comes up at some point. That would be equivalent to #3, correct? Yes, HTML, CSS, etc. do #3. -- http://annevankesteren.nl/
Re: [whatwg] Encoding: API
On Thu, Oct 18, 2012 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: http://encoding.spec.whatwg.org/#api Btw, I changed these things: * TextDecoder.decode()'s view argument is no longer optional. Why should it be? * TextEncoder.encode()'s input argument is no longer nullable. Again, why should it be? I also raised the issue of whether TextEncoder should really support utf-16/utf-16be as the encoding standard tries to deprecate non-utf-8 encodings. -- http://annevankesteren.nl/
Re: [whatwg] Encoding: API
On Thu, Oct 18, 2012 at 3:54 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 18, 2012 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: http://encoding.spec.whatwg.org/#api Btw, I changed these things: * TextDecoder.decode()'s view argument is no longer optional. Why should it be? It buffers the EOF byte when in streaming mode, eg. when the last byte of the stream is a UTF-8 continuation byte, so any encode errors are triggered. * TextEncoder.encode()'s input argument is no longer nullable. Again, why should it be? Likewise for encoding, to flush errors for trailing high surrogates. I also raised the issue of whether TextEncoder should really support utf-16/utf-16be as the encoding standard tries to deprecate non-utf-8 encodings. The whole point of this API is to support legacy file formats that use other encodings. (It's probably questionable to not support other encodings, too, eg. filenames in ZIP file headers, but starting out with Unicode is fine.) -- Glenn Maynard
Re: [whatwg] maincontent element spec updated and supporting data provided
I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. Naturally, anyone is welcome to make proposals and discuss use cases, but I would encourage people participating on this mailing list to focus first on establishing use cases, to avoid returning to topics that have previously been discussed without adding new information, and to avoid discussing minutiae of proposals before firmly establishing that there are solid use cases. On Wed, 17 Oct 2012, Steve Faulkner wrote: What is apparent from the home page data in the sample: * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main|id=main-content used on 39% of the pages in the sample) This is not new information: https://developers.google.com/webmasters/state-of-the-web/2005/classes The thing is, we already have elements for these cases. Take the pages in this list: http://www.html5accessibility.com/tests/HTML5-main-content/ Site 1 uses id=main-nav where it could use nav, id=main where it could use article, and has multiple divs for styling that would not be removed if we added one more element regardless of its semantics, and uses id=content but doesn't need to to achieve its style. Site 2 uses id=main where article would be suitable, class=main and class=content for cases where a broad main content semantic would not be, and has multiple divs with IDs such that adding a semantic for its element with id=content wouldn't solve the problem of needing divs for its style. Site 3 uses id=content where aside or article would be appropriate, uses an a, of all things, to wrap ads that could arguably be articles in their own right, and uses div id=main as part of a cascade of divs for stylistic reasons (I don't understand its use of 'overflow' to achieve its effect, but I find it hard to believe that it's necessary...). Site 4 has elements with id=content, left_main, right_main, comment_main, etc, and styles its id=content element in a way that could just as easily be achieved without the element being present at all. Plus, this page has deep div stacks that again wouldn't be resolved just by taking away one of the main layers into its own element. Site 5 has multiple elements that could be considered to wrap the main content, with such divs nested at least five deep at one point (content, rightside (where the right side is the main part of the page), module, module_body, chuxing_div...). I could go on, but the point is that this is exactly the results we got in 2005/2006 when we last studied this. There are sections of the page that can legitimately be marked up, for which we've now got header, footer, article, nav. Those tend to be unambiguously recognisable. There are other more generic sections that are still semantically clear sections, for which we've now got section, hr. And then there's the divisions that really are there for stylistic reasons, not semantic reasons. They're not necessary for accessibility (which can determine the position of the main content from the other elements), there tends to be a lot of them at once, different pages tend to have different precise needs for them, and for these, we have div. On Thu, 18 Oct 2012, Henri Sivonen wrote: If Hixie had added this element in the same batch as section, article and aside, he would have made the parsing algorithm similarly sensitive to this element. However, I'm inclined to advise against changes to the parsing algorithm at this stage (you have none; I am mainly writing this for Hixie), since it would move us further from a stable state for the parsing algorithm and, if the main element is used in a conforming way, it won't have a p element preceding it anyway. If main had a use case, I would definitely think we should change the parsing algorithm -- not changing it makes the element essentially unusable, IMHO. But that's academic, since the element has no useful purpose, isn't necessary, and is thus not part of HTML. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Feedback on HTML elements
On Fri, 28 Sep 2012, Ian Yang wrote:
On Fri, Sep 28, 2012 at 2:27 AM, Ian Hickson i...@hixie.ch wrote
On Mon, 16 Jul 2012, Ian Yang wrote:
But your opinion does remind me of the small element. That element
is a perfect example of introducing and using an element simply for
its rendering. Unlike ul and ol, it's not meaningfully named at
all. Honestly, I'm not a huge fan of recycling a deprecated element.
If we need an element for side comments, we could introduce
comment or c. If we need an element for document info, we could
introduce info. That would make HTML elements more meaningfully
named.
The names are opaque -- most people who write HTML don't speak English
as their first language, if at all, so we can't really rely on the
element names to convey the semantics.
We couldn't use comment, some browsers default to hiding comment
elements.
We could introduce c or info, but small has the advantage that
it already renders in an appropriate way in legacy user agents.
When it comes to conveying semantics, many existing HTML elements' name
already have such an issue. So developers should at least have a basic
understanding of English. After all, it's not hard to learn a few more
English words. :-)
More people speak Chinese than English, and it's not too hard to learn a
bit of Chinese, right? Maybe we should change HTML to use Chinese names
instead. :-)
In practice, I would expect that most authors learn HTML in their native
tongue, and treat the element names as opaque strings.
The displaying of new elements like c or info could be fixed by
using javascript like how we have fixed the displaying of header,
footer, article, .. etc in legacy browsers.
Indeed, for some elements we have done this (e.g. mark).
Personally I'd recommend using structures like:
plabelPhone input name=phone type=tel/label/p
...for each line, but the effect, and semantics, are the same.
That structure is simple and elegant. Yet in some circumstances, that
might cause styling issues. For example, developers might want to float
the label text to right or slightly adjust its vertical aligning.
Indeed.
And usually life cycle type contents are presented as circles.
Without li(s), it will be hard to style them.
This is something we should fix in CSS.
Yes, we could do absolute positioning for every dt and dd, but
that's troublesome. With the optional use of li, we only need to
position lis.
I mean it's something that we should make easy in CSS. That is, CSS should
have a way to do this that doesn't require complicated positioning of each
dt and dd or whatnot. For example, a way to imply a pseudo-element
around a pattern of elements.
::pseudo(from: dt:first-child, dd + dt;
to: dd:last-child, dt:matches(# + dd)) { }
...or some such.
We need to be compatible with the browsers. Adding new features is
something we have to do very carefully to avoid not breaking the
browsers.
Since the proposed use of li is optional, developers who want to use
it should include closing tags (/li, /dt, and /dd). That solves
the issue.
I don't think that's solving the issue, I think that's asking authors to
paper over the issue for us.
On Mon, 15 Oct 2012, Willabee Wombat wrote:
Please see http://forums.whatwg.org/bb3/viewtopic.php?f=3t=5081 for the
background of my request to have acronym added to the HTML5 spec.
Without getting into all of the discussions about what is an
abbreviation and what is an acronym, I would like to propose the
acronym element be added to the semantics of HTML5 with a clear
indication of its semantic use;
acronym the word is spoken.
abbr the abbreviation is spelt out, letter by letter.
This, unfortunately, doesn't cover the full range of abbreviations in
English (let alone other languages).
Is SQL spoken or spelt out? Or PNG?
Is XMLHttpRequest spoken or spelt out?
Are JPEG or MPEG spoken or spelt out? How about IPSEC?
And that's not even looking at issues like translation (such as what Karl
pointed out), or other complications in other languages.
Nice and simple. Everyone should understand the semantics.
Unfortunately, language is anything but simple. :-)
- Screen readers can use it to say or spell out the word.
Screen readers have to solve this problem in the absence of markup anyway,
since not everyone uses these elements. So they tend to use heuristics and
dictionaries, which make this a non-problem.
- Designers can use these different elements to stylistically make the
semantics obvious to visual users.
The class attribute can be used to do this. This page on Wikipedia
suggests that in practice there are many styles and it's not clear that
two elements would make matters easier:
http://en.wikipedia.org/wiki/Acronym_and_initialism
- There will be no need to add a class name to these elements for
[whatwg] Tracks and cues
On Wed, 25 Jul 2012, Henri Sivonen wrote: On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: But you can use cue.text and parse it as a SVG fragment. That would be RSS all over again. :-( The difference is that here the parsing at each layer is fully defined. It's more like JSON, where a key's value can be HTML or XML or SVG or whatever. On Wed, 25 Jul 2012, Silvia Pfeiffer wrote: If we are very clear about what will be in the cues and that it will always be just SVG, we could just create a @kind=svg. IMHO the idea of putting SVG in cues seems to somewhat miss the point. SVG already has a timeline, it already supports synchronisation with videos, it should just be used that way. On Wed, 26 Sep 2012, Cyril Concolato wrote: Has it been considered adding another method to add cues to a track? Something like addCues(DOMString text) where the text is not only one cue (like in the TextTrackCue ctor) but where the text would be multiple cues as written in a WebVTT file? Just use a track element to point to the file. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Canvas hit regions feedback
On Fri, 6 Jul 2012, Maciej Stachowiak wrote: On Jul 5, 2012, at 11:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor eocon...@apple.com wrote: As things currently stand in the spec, implementations basically need to keep N+1 bitmaps per canvas, where N is the number of hit regions. I doubt any implementors would be enthusiastic to implement hit regions like this. From a WebKit perspective, we'd much prefer keeping a Path for each hit region, and then simply using isPointInPath for hit testing. This also implies that the current piggybacking of Clear regions that cover the pixels in clearRect() could go away. Yay! :) Bog-standard hit-testing algorithms apply. Keep a single extra canvas around, draw each region into it with a different color. When you're hit-testing, just see what color that pixel is, and look up which region is associated with it. This is extremely fast and simple to implement, and has all the right properties - the topmost region for a given pixel is the one returned. It also doubles the memory cost of the canvas if you use hit regions, which is likely much more than path-based hit testing would cost. Indeed, as with many cases where there are multiple ways to implement something, the different implementation strategies have different tradeoffs. On Fri, 6 Jul 2012, Rik Cabanier wrote: On Fri, Jul 6, 2012 at 5:40 PM, Dean Jackson d...@apple.com wrote: We're aware of this technique, but it has a couple of obvious issues: 1. It requires us to create a duplicate canvas, possibly using many MB of RAM. It's generally going to be less memory to keep a list of geometric regions. And performance won't be terrible if you implement some spatial hashing, etc. 2. It doesn't allow for sub pixel testing. In your algorithm above, only one region can be at a pixel (which also means it isn't our standard drawing code with anti-aliasing). Consider a zoomed canvas, where we might want more accurate hit testing. Wouldn't thess problems go away if you use an OpenGL/DirectX backend to Canvas like so many browsers are doing? That way, you only need the display list for hit testing and just render the region for hit testing (ie http://www.opengl.org/archives/resources/faq/technical/selection.htm) That would be one of the possible implementations, as far as I can tell. On Wed, 25 Jul 2012, Steve Faulkner wrote: From my reading of the hitregion() [1] section of the spec it is unclear to me whether click events work on unbacked regions I'm not sure what you mean by work. Can you elaborate? It is clear that mouse move events can be used, but will developers be able to detect and make use of click events on backed regions? The spec doesn't distinguish between the types of mouse events. See the section starting around here: http://www.whatwg.org/specs/web-apps/current-work/#dom-mouseevent-region On Thu, 26 Jul 2012, Steve Faulkner wrote: In this case unbacked regions can be used to designate interactive regions, but the interactivity is confined to mouse based events, as the region is not associated with a DOM element that can receive focus. The specification describes a mechanism by which hit regions that do not have explicit controls are indistinguishable to the user from regions that do have explicit controls (and indeed, from any other element in the DOM). See the section in the spec that starts Each hit region should be handled in a fashion equivalent to a node in a virtual DOM tree. In particular, this means that accessibility tools that use a separate accessibility tool focus (e.g. the VoiceOver focus), and touch devices that provide haptic feedback, should work fine. Users who are keyboard- bound but unable to use an accessibility tool are screwed, but then they're screwed anyway since not everything that's interactive is focusable even at the best of times. :-( (I speak as one such user.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] maincontent element spec updated and supporting data provided
On Oct 18, 2012, at 2:36 PM, Ian Hickson wrote: I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. Off-topic, but just for the record: there was no expectation that the RICG’s proposal would simply be accepted wholesale, for obvious reasons—just that we would be able to collaborate with the WHATWG on it. It wouldn’t have made much sense for us to call it a “proposal” otherwise, after all. :) On-topic: the `main` class/ID pattern is an exceedingly common one, for sure. I use it all the time myself, in conjunction with `role=main`. I was originally of the mind that the role of “primary content” was served by the first `article` element within the document, but where the first `article` just represents the first sectioned stand-alone content in the document, it could be something like an infographic — capable of functioning independent of the surrounding document, but not the entirety of the primary content. Given the clear meaning of the proposed element, the low barrier to adoption by web developers, and the potential benefits this could have in terms of syndication and accessibility: it certainly sounds interesting! The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step!
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Ian, I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. Ian is right, this is not part of the WHATG HTML specification, it is an HTML extension specification that I am developing through the W3C HTML WG with the aim of progressing the extension to a point where it can be folded back into HTML 5.0 if it meets the CR exit criteria or HTML 5.1. And i guess that if it is implemented that it will also become part of the WHATWG HTML specification. I have mailed the WHATWG list and asked for feedback on it as this is where some HTML standards developers and some implementers participate. In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. There are use cases, and there is as much of a problem to be solved as there was for the addition of header/footer etc, but you do not agree that they are valid which, is fine, other people think they are valid. This is not new information: https://developers.google.com/webmasters/state-of-the-web/2005/classes It is new information, its data about the use of id's not classes, there is no data on id's in the documents you linked to. there is also no data in the linked ocuments about the relationship between id values and their use as targets of 'main content' links or data about the relationship between the use of role=main and such id values. Also its fresh data from 2012, not 2005. Site 1 uses id=main-nav where it could use nav, id=main where it could use article, and has multiple divs for styling that would not be removed if we added one more element regardless of its semantics, and uses id=content but doesn't need to to achieve its style. Site 2 uses id=main where article would be suitable, class=main and class=content for cases where a broad main content semantic would not be, and has multiple divs with IDs such that adding a semantic for its element with id=content wouldn't solve the problem of needing divs for its style. Site 3 uses id=content where aside or article would be appropriate, uses an a, of all things, to wrap ads that could arguably be articles in their own right, and uses div id=main as part of a cascade of divs for stylistic reasons (I don't understand its use of 'overflow' to achieve its effect, but I find it hard to believe that it's necessary...). Site 4 has elements with id=content, left_main, right_main, comment_main, etc, and styles its id=content element in a way that could just as easily be achieved without the element being present at all. Plus, this page has deep div stacks that again wouldn't be resolved just by taking away one of the main layers into its own element. Site 5 has multiple elements that could be considered to wrap the main content, with such divs nested at least five deep at one point (content, rightside (where the right side is the main part of the page), module, module_body, chuxing_div...). What you are saying does not invalidate the uses case for a maincontent element.the examples illustrate a correlation between the use of the cited id's on an element that is used as a container for the main content of a page, and a high correlation between the use of such id's being used with role=main and as the target form 'skip to main content' links. i.e as a useful semantic identifier. There are sections of the page that can legitimately be marked up, for which we've now got header, footer, article, nav. Those tend to be unambiguously recognisable. The data strongly suggests that there is a section of the page that can be identfied as the main content area, which tends to be unambiguously recognisable. It should be noted that while I provide the links to the source for the data I provided. there is no such provision in the data you cite from 2005 from which you based the inclusion of various structural elements. regards SteveF On 18 October 2012 20:36, Ian Hickson i...@hixie.ch wrote: I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. Naturally, anyone is welcome to make proposals and discuss use cases, but I would encourage people participating on this mailing list to focus first on establishing use cases, to avoid returning to topics that have previously been discussed without adding new information, and to avoid discussing
Re: [whatwg] A mechanism to improve form autofill
On Tue, Oct 16, 2012 at 1:23 AM, Ilya Sherman isher...@chromium.org wrote: On Thu, 26 Jul 2012, Aryeh Gregor wrote: Government-issued ID numbers might be worth adding. In America, social security numbers are sometimes used for this purpose, but are treated as semi-secret, so you usually don't enter them on web forms. (My American college did use my social security number as an ID number, but not in web forms as far as I remember.) But in Israel, and I assume some other countries, there are national ID numbers that are considered public info. E.g., my Israeli id number (mispar zehut) is 332752187. It's printed on my checks and things like that, so it's no secret, and since it's guaranteed to exist and be unique, various institutions use it for login instead of or in addition to a username -- my bank, health insurance provider, etc. I haven't added this yet. I also haven't added: - payment instrument type - payment instrument start date - payment instrument issue number (for Maestro) I also haven't removed, as some people suggested, the three cc-name subfields. I'm open to making all these changes, but figured I would get some more input on them first, in particular from Ilya who did the research to come up with the original set of fields. I have seen a relatively high number of Chrome bug reports requesting better handling of (e.g. government) ID numbers. One example: [ http://code.google.com/p/chromium/issues/detail?id=64433 ]. I think it would be helpful to add these to the spec; though as subsequent posters have noted, there's a lot of potential complexity in how these should be represented. This might fall under the broader class of identity-related fields, which I think merit their own carefully thought out set of tokens. There was some work done on the beginnings of such a specification -- see https://wiki.mozilla.org/Identity-inputs -- but my current understanding is that this is an area in need of further development. The payment instrument type is almost certainly appropriate to add -- it is included on almost every website that I've encountered that includes payment card fields. It was an oversight on my part to omit it from the initial proposal. The other two payment instrument field types I haven't encountered on the Web, as far as I can recall. So, based on my data set accumulated while working on Chrome Autofill, I'm ok with leaving these out of the spec for now. However, my experience is biased toward US websites; it's possible that these fields are more prominent internationally. The three cc-name subfields are split out surprisingly often on existing websites. I was initially opposed to including these in the spec; but that data in support of them was overwhelming. Finally, I have gotten a request to include a field type for bank account numbers, though I have only seen this info actually requested on a small handful of extremely prominent (and generally trusted) websites: Amazon, PayPal, and I think Google Wallet. David Holloway reminded me that bank account numbers are also commonly requested when filling out United States tax forms. I have seen this information requested for tax returns on [ https://turbotax.intuit.com ]; and David pointed me to [ https://gate.link2gov.com/sfpropertytax/PropertySearch.aspx?TaxType=Secured ], which allows you to pay be e-check and asks for your bank account's routing and account numbers.
Re: [whatwg] maincontent element spec updated and supporting data provided
hi Mat, The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step! right, will work on it. Hixie, can you point me to the uses cases developed for adding header/footer/section/article/aside etc? As it would be good to have some related source material to work from. I had a look on the WHATWG wiki and serached the WHATWG mail archive and couldn't find anything. regards SteveF On 18 October 2012 22:27, Mathew Marquis m...@matmarquis.com wrote: On Oct 18, 2012, at 2:36 PM, Ian Hickson wrote: I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. Off-topic, but just for the record: there was no expectation that the RICG’s proposal would simply be accepted wholesale, for obvious reasons—just that we would be able to collaborate with the WHATWG on it. It wouldn’t have made much sense for us to call it a “proposal” otherwise, after all. :) On-topic: the `main` class/ID pattern is an exceedingly common one, for sure. I use it all the time myself, in conjunction with `role=main`. I was originally of the mind that the role of “primary content” was served by the first `article` element within the document, but where the first `article` just represents the first sectioned stand-alone content in the document, it could be something like an infographic — capable of functioning independent of the surrounding document, but not the entirety of the primary content. Given the clear meaning of the proposed element, the low barrier to adoption by web developers, and the potential benefits this could have in terms of syndication and accessibility: it certainly sounds interesting! The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step!
Re: [whatwg] Character-encoding-related threads
On Fri, 13 Jul 2012, Jukka K. Korpela wrote: 2012-06-29 23:42, Ian Hickson wrote: Currently you need a DOCTYPE, a character encoding declaration, a title, and some content. I'd love to be in a position where the empty string would be a valid document, personally. Is content really necessary? The validator.nu service accepts the following: !DOCTYPE htmltitle/title It's a SHOULD-level requirement; search the spec for the word palpable. But the title element isn't really needed, and unless I'm mistaken, the current rules allow its omission under some conditions - which cannot be tested algorithmically, so conformance checkers should issue a warning at most about missing title. It might be better to declare title optional but strongly recommend its use on web or intranet pages (it might be rather irrelevant in other uses of HTML). That's basically what the spec says -- if there's a higher-level protocol that gives a title, then it's not required. It's only required if there's no way to get a title. Are there any situations that this doesn't handle where it would be legitimate to omit a title element? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] maincontent element spec updated and supporting data provided
On Fri, 19 Oct 2012, Steve Faulkner wrote: Hixie, can you point me to the uses cases developed for adding header/footer/section/article/aside etc? As it would be good to have some related source material to work from. I had a look on the WHATWG wiki and serached the WHATWG mail archive and couldn't find anything. There's a number of use cases, and I don't recall which we were looking at specifically at the time (it was many years ago), but off the top of my head: being able to jump straight to the main content of the page, being able to jump to the page's navigation, being able to style the header and footer specifically, being able to move sections up and down the outline (e.g. turn a sub-section into a sub-sub-section) without having to update the markup (e.g. h4 to h5), being able to mark parts of the page as being non-critical (e.g. in the spec, a note or example), etc. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Separating intrinsic sizing out from the iframe seamless attribute
On Wed, 18 Jul 2012, Jonathan Watt wrote: It seems like there should be a way to get iframe to size to the intrinsic size of the embedded content without having style from the embedding document inherit into the embedded document. Could we have a way to do just the intrinsic sizing please? On Wed, 18 Jul 2012, Ojan Vafai wrote: I made a proposal for this at the end of http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036584.html. The best way to get this specced is to provide additional use-cases (for having intrinsic sizing without inheriting style) in addition to use case #3 in my email. On Wed, 18 Jul 2012, Jonathan Watt wrote: The use cases are simple. I want to be able to embed SVG as-a-document (not as-an-image) and have it size to its intrinsic size, without messing up the style of the SVG. That's not a use case, that's a solution. What's the actual use case? i.e. why do you want to embed SVG as a document? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On Wed, 29 Aug 2012, Fred Andrews wrote: From: i...@hixie.ch On Fri, 8 Jun 2012, Mark Callow wrote: On 08/06/2012 06:09, Ian Hickson wrote: The dire warning doesn't work. I'm just saying that's the direction that operating system vendors have been going in; that disallowing it in the browser case is not a different direction, it's consistent with the industry's direction as a whole. The platform providers want control so they can extract money from application developers; they do it under the guise of safety security so people will go along with it. Governments get control over people in the same way. In both cases it is an existential threat to freedom and civil liberties. If one works from these assumptions, why would we assume that it is nonetheless possible for us to specify something that works against these motivations? Putting something in the spec doesn't magically make it appear in browsers. Some statements in the spec could help defend privacy and freedom even if these are only implemented in a limited number of browser or even only as add-ons. Some examples: 'The user-agent is not intended to accurately identify the browser and is user selectable and could well be set to a known common browser user-agent string to help preserve user privacy and prevent fingerprinting. Further using a trademark in a user-agent gives everyone the right to use the trademark within their user-agent.' If this language is not acceptable then we just need to remove the user-agent from the spec. Do you think adding this would increase the number of browsers that let you change the user agent string? On what do you base your answer? As far as I can tell, browsers and extension writers have not needed the spec to say anything like this to implement such features. (In any case, User-Agent is an HTTP feature, so out of scope for HTML.) 'Web browser clients may well be implemented 'in the cloud' as a service, and this could well mean that an IP address does not correspond to a user but rather the cloud service host.' [Defend Opera Mini and other innovations] What do you think adding this to the spec would do? 'The execution of Javascript in the browser and thus the interpretation of any algorithms are at the discretion of the user. The user may disable Javascript or modify the interpretation of Javascript code to suit their consumption and may use proxies to answer or filter communication from the browser. Specifically the web browser platform is not intended for the implementation of any effective DRM measures.' The spec already says things to this effect. Browsers already support disabling script and pretty much all of them, including the mainstream ones, have elaborate debuggers built-in. What effect do you think adding the paragraph above would have? 'Javascript is delivered in source form so it is not intended to provide protection from being disassembled. Since browsers interpret Javascript as a natural part of presenting content and since they may well need to understand the code to implement control mechanisms it is specially not intended to provide protection from reverse engineering.' This seems to be something for the JavaScript spec (or the JS MIME type spec), not the HTML spec. 'The presentation of web content is at the discretion of the user and their browser may selectively present content, transform the content, or augment the content as part of the private consumption and presentation process.' This is elaborately described in the spec already. What would saying it even more do? 'For example a cloud service many implement a browser that presents only the audio from videos.' [Google seem to have already taken down some such sites] Not sure what cloud service many implement a browser means, but if you mean that a server can download an MPEG file, strip its video, and return just the audio, then sure, but I don't see what that's got to do with HTML. Heck, HTML supports that natively, just point audio at a video file and it'll strip the video. 'A web browser may well be implemented as distributed services, transforming and caching content for consumption at a time and place chosen by the user. For example a 'cloud browser' may transform a website video and deliver it to a remote mobile device for presentation at a later time.' What effect do you think saying this in the HTML spec would have? Are you saying that if the spec _doesn't_ say it, people are going to avoid writing proxy servers, caching servers, format-shifting programs, or time-shiting devices? This seems unlikely, since there are entire industries built around these concepts. 'The manner in which a web browser presents content or interprets Javascript are a private matter of the user and the web browser may well implement measures to maintain privacy and block any
Re: [whatwg] Separating intrinsic sizing out from the iframe seamless attribute
On Thu, Oct 18, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 18 Jul 2012, Jonathan Watt wrote:
The use cases are simple. I want to be able to embed SVG as-a-document
(not as-an-image) and have it size to its intrinsic size, without
messing up the style of the SVG.
That's not a use case, that's a solution. What's the actual use case? i.e.
why do you want to embed SVG as a document?
Further, CSS should be adding a mechanism to reset styles anyway - as
soon as fantasai and I have another free day together to write the
Cascade module, we'll add an 'all' property, which only takes the
global keywords.
Once we then add the 'default' global keyword (lets you reset to the
UA stylesheet), you can just say :root { all: default; } in your SVG
document, and not worry about inheritance polluting your SVG styling.
That doesn't help the import all the stylesheets into the iframe
part, but shrug.
~TJ
Re: [whatwg] maincontent element spec updated and supporting data provided
On Thu, Oct 18, 2012 at 11:36 AM, Ian Hickson i...@hixie.ch wrote: I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. I thought the requirement was that it got adoption by implementations? In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. I believe there are different opinions about this. I don't have a strong opinion myself, but I don't believe the case is as clear-cut as the above sentence makes it sound. Naturally, anyone is welcome to make proposals and discuss use cases, but I would encourage people participating on this mailing list to focus first on establishing use cases, to avoid returning to topics that have previously been discussed without adding new information, and to avoid discussing minutiae of proposals before firmly establishing that there are solid use cases. Agreed. / Jonas
Re: [whatwg] Character-encoding-related threads
2012-10-19 2:09, Ian Hickson wrote: On Fri, 13 Jul 2012, Jukka K. Korpela wrote: [...] It might be better to declare title optional but strongly recommend its use on web or intranet pages (it might be rather irrelevant in other uses of HTML). That's basically what the spec says -- if there's a higher-level protocol that gives a title, then it's not required. It's only required if there's no way to get a title. My point is that the title may be irrelevant, rather than specified using a higher-level protocol. Are there any situations that this doesn't handle where it would be legitimate to omit a title element? Perhaps the simplest case is an HTML document that is only meant to be displayed inside an inline frame and containing, say, just a numeric table. It is not meant to be found and indexed by search engines, it is not supposed to be rendered as a standalone document with a browser top bar (or equivalent) showing its title, etc. The current wording looks OK to me, and it to me, it says that a title is not needed when the document is not to be used out of context: The title element represents the document's title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results. http://www.whatwg.org/specs/web-apps/current-work/#the-title-element Authors may still wish to use a title element in a document that is to be just shown in an inline frame, but it is comment-like then. I don't think it's something that should be required (even in a should clause). Yucca
