Re: [whatwg] Nullable types and MediaStreams
Cameron McCormack wrote: Per-Erik Brodin: The DOMString arguments 'options' and 'configuration' are never referred to as being null, and thus I think it is safe to assume that they will not be null and that the default conversion rules apply (http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString). The callback arguments are all referred to as being null so I think it is safe to assume that they can be null. Interface types now *do not* include null as one of their values unless you make the type nullable explicitly. The HTML spec hasn’t been updated for this yet, though I have written a patch to do so: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640 I am aware of that. What I mean is the conclusions you can draw from reading the spec text. I would expect the expected behavior to be the same after this change, right? //Per-Erik
Re: [whatwg] Nullable types and MediaStreams
On Tue, 14 Jun 2011, Per-Erik Brodin wrote: Cameron McCormack wrote: Per-Erik Brodin: The DOMString arguments 'options' and 'configuration' are never referred to as being null, and thus I think it is safe to assume that they will not be null and that the default conversion rules apply (http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString). The callback arguments are all referred to as being null so I think it is safe to assume that they can be null. Interface types now *do not* include null as one of their values unless you make the type nullable explicitly. The HTML spec hasn’t been updated for this yet, though I have written a patch to do so: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640 I am aware of that. What I mean is the conclusions you can draw from reading the spec text. I would expect the expected behavior to be the same after this change, right? Thanks to Cameron's fantastic work, this is fixed now, so there should no longer be a need for reading between the lines. Please let me know if it's still ambiguous, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Option label, textContent and value
On Tue, 8 Mar 2011, Markus Ernst wrote: In 4.10.12 on the Option element, the spec states: The label attribute provides a label for element. The label of an option element is the value of the label attribute, if there is one, or the textContent of the element, if there isn't. The value attribute provides a value for element. The value of an option element is the value of the value attribute, if there is one, or the textContent of the element, if there isn't. It looks like this needs clarification for the case both label attribute and text content are present, as UAs do not implement this consistently: select option label=Label1TextContent1/option option label=Label2TextContent2/option /select - IE 8, Opera 11 and Chrome 9 display Label1 and Label2 - Firefox 3.6 displays TextContent1 and TextContent2 Firefox's behavour seems to be contradictory to the spec, which gives the label attribute precedence. Yes, the behaviour you describe for Firefox is wrong. Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist The difference is that the value is typically shown in the datalist case. I'd propose to slightly change the specification to treat the value the same, regardless whether it is given in the value attribute or in the text content, and to get the label, where the label attribute is missing, from the value rather than from the text content: That would result in redundant UI. On Tue, 8 Mar 2011, Jukka K. Korpela wrote: Technically it's a bit more complicated: The contents of the [datalist] element represents fallback content for legacy user agents, intermixed with option elements that represent the predefined options. In the rendering, the datalist element represents nothing and it, along with its children, should be hidden. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element So you _could_ use option value=xxxfoobar/option inside datalist, but foobar would be ignored by conforming browsers - it would only appear on older browsers, hopefully constituting part of well-designed fallback content. It would also be used as the label in any suggestions list. On Tue, 8 Mar 2011, Markus Ernst wrote: Yes... all I meant was actually that I would consider it consistent if both select optionfoo /select datalist option value=foo /datalist work the same regarding the label. They do. The label comes from the label= attribute if present, or else the textContent. It's exactly the same. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Nullable types and MediaStreams
Great work! /Tommy On Tue, Jun 14, 2011 at 09:05, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Jun 2011, Per-Erik Brodin wrote: Cameron McCormack wrote: Per-Erik Brodin: The DOMString arguments 'options' and 'configuration' are never referred to as being null, and thus I think it is safe to assume that they will not be null and that the default conversion rules apply (http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString). The callback arguments are all referred to as being null so I think it is safe to assume that they can be null. Interface types now *do not* include null as one of their values unless you make the type nullable explicitly. The HTML spec hasn’t been updated for this yet, though I have written a patch to do so: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640 I am aware of that. What I mean is the conclusions you can draw from reading the spec text. I would expect the expected behavior to be the same after this change, right? Thanks to Cameron's fantastic work, this is fixed now, so there should no longer be a need for reading between the lines. Please let me know if it's still ambiguous, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
[whatwg] Interpretation issue: can section be used for extended paragraphs?
On Thu, 10 Mar 2011, Jukka K. Korpela wrote: The p element (ever since it became an element) has always allowed inline (text-level) content only, and no change is planned to this in HTML5. Actually a change was planned, and executed, early on in the development of HTML5. It had to be reverted for various reasons, a long time before we dropped the 5, even. One of the reasons was that it wasn't necessary. Under these circumstances, what should we say to people to need to use paragraphs that contain lists, for example? That paragraphs don't contain lists; when a sentence has * this * structure, ...it is in fact two paragraphs and a bullet list. A paragraph, in the old typographic sense, may contain lists. That is a somewhat debatable point, but luckily it is also somewhat orthogonal to the real issues you raise. A sentence in the text may continue with list items, displayed e.g. as a bulleted list. So the list breaks the paragraph as a block of text but not logically - the list items are part of the sentence just as they would be if they were just mentioned in the text, for example using 1) numbers in the text, 2) letters in the text, or 3) no special notation. Indeed, but block of text is pretty much what a paragraph is -- it isn't a logical construct. It's quite possible, if rare, for a sentence to span paragraphs even without lists being involved... Take, for instance, the first... ...no, the second... ...no, the third, of these blocks of text. That sentence spans three paragraphs. That's not a problem, IMHO. The HTML(5) paragraph concept is different, so in HTML terms, such a paragraph would need to consist of a P element followed by a UL (or OL) element. Indeed. There is an apparent need for indicating in markup that the two belong to together, We need more than an apparent need, we need a concrete real need, before we add a feature. a) for styling purposes (you need a container element so that you can specify, without clumsily using classes on both the P and the UL, e.g. that vertical spacing be reduced or zero) div handles this case: divThis sentence ol licontains lia list /ol ...and is made of four paragraphs but can be styled as one since the lt;div element is used instead of lt;p./div Note that the semantics turn out the same as if you'd used ps in there as well, as in: divpThis sentence/p ol lipcontains/p lipa list/p /ol p...and is made of four paragraphs but can be styled as one since the lt;div element is used instead of lt;p./p/div ...because of the definition of paragraph in HTML now. b) to ease handling in scripts Could you give a concrete example of why scripts would need to manipulate paragraphs in this way? c) to act as documentation in the source code, warning future editors of the document that neither the P element nor the UL element should be edited in isolation but only considering the other part as well. Isn't that pretty obvious from the fact that the sentence spans multiple elements? I mean, if an editor is ignoring the very prose that they are editing, I don't think any amount of markup can really save them. There are less apparent needs, or possibilities, too - e.g., 1) to communicate to any interested software that the elements are coupled, treating occurrences of a word as occurring in the same extended paragraph for the purposes of indexing, searching, etc., Can you give a concrete example of this? 2) to tell a grammar checker that the P element just _appears_ to end abruptly), A grammar checker, much like a human, would presumably operate on the text itself and could therefore easily detect that the sentence spanned multiple elements (or at least, as easily as if the sentence used phrasing elements in the same places). 3) to inform editing software that e.g. triple-clicking the paragraph, for the purpose of moving it elsewhere, should also select the UL element. It's not clear that this is desireable, but if it is, then div with a class specific to the editor would be able to handle this case, as far as I can tell. It's hard to know without more specifics. I guess some of these needs, especially the most practical (in a sense) styling issue, could be addressed by simply putting the P and UL elements inside a SECTION element: That would be abuse of section semantics, but it's the right idea. Just use div instead. Should this even be mentioned, descriptively, as a common use case, or as an example of inappropriate use, depending on the position that will be taken? If it's something that's actually important, I'm happy to mention the div trick. Let me know if you think that would help. On Thu, 10 Mar 2011, Andy Mabbett wrote: Consider a more complex scenario: pI always like to eat these cheeses:/p ul liCheddar liStilton liRed Lester /ul pbut I enjoy them most with one of these
Re: [whatwg] First Encounter with HTML
On Fri, 11 Mar 2011, �~Y��~Y��~Dνιηα�~Uн�~Y��~Y� wrote: Respected Sir, I am very new to HTML... I want to learn HTML from scratch to advanced HTML5.. So cn you please suggest me some sites and books or other web resources for COMPLETE study material of HTML n other web technologies... Please help... Thanking you in advance... I don't know how helpful it would be, but http://developers.whatwg.org/ might be of interest. Beyond that, HTML tutorials of times gone by are as good a place as any to start. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Option label, textContent and value
On Tue, Jun 14, 2011 at 12:11 AM, Ian Hickson i...@hixie.ch wrote: Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist The difference is that the value is typically shown in the datalist case. At least input type=email seems like a very common example where you'd want to show a label. Here you likely will want to show peoples names, but choosing a name would use the email address as the .value for the input. / Jonas
Re: [whatwg] Option label, textContent and value
On Tue, 14 Jun 2011, Jonas Sicking wrote: On Tue, Jun 14, 2011 at 12:11 AM, Ian Hickson i...@hixie.ch wrote: Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist The difference is that the value is typically shown in the datalist case. At least input type=email seems like a very common example where you'd want to show a label. Here you likely will want to show peoples names, but choosing a name would use the email address as the .value for the input. Absolutely. My point is just that if the label is missing (no name) you'd still show the value, unlike in select, where historically UAs never show the value of the value= attribute. In fact you'd likely show the value in both cases, as in some of the sample UI images shown in the spec (where the value is on the left, autocompleting, and the label is on the right where available). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
Am 14.06.2011 09:32 schrieb Ian Hickson: On Fri, 11 Mar 2011, Markus Ernst wrote: Instead of a new paragraph concept, there could also be a new concept for inline (resp. Phrasing Content) lists. The concept is actually not too new - for quotes, e.g., we've had both block levelblockquote and an inline levelq elements for long. Why not the same for lists? Consider this markup of Andy's use case: pI always like to eat these cheeses: il iliCheddar/ili, iliStilton/ili, and iliRed Lester/ili, /il but I enjoy them most with one of these biscuits: il iliwheat crackers/ili, ilirye crackers/ili, ilidigestives/ili, /il and some chutney./p il stands for inline list,ili for inline list item (it's a pity we can't reuseli for BC reasons). Conforming UAs would be required to ignore any content in anil element, except it is in anili element. Like that, the above example would be perfectly readable in legacy UAs, but make sense in HTML5-capable UAs. It would even be easy to stlye the output for legacy UAs supporting display:list-item, as this example illustrates: http://www.markusernst.ch/stuff_for_the_world/list-test.html What problem does this solve? It solves the first use case Jukka mentioned in his original post: Am 10.03.2011 09:20 schrieb Jukka K. Korpela: The p element (ever since it became an element) has always allowed inline (text-level) content only, and no change is planned to this in HTML5. Under these circumstances, what should we say to people to need to use paragraphs that contain lists, for example?
[whatwg] Microdata property sharing with itemref
A question came up in the Schema.org discussion group today: http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/69b733066ae7?pli=1 The question was how to fix http://www.2gc.co.uk/a2gc-people to link together properties that were in different parts of the document into a single item. The answer is of course to use itemref, here simplified even further to illustrate: div itemscope itemtype=http://schema.org/Organization; p itemprop=name2GC Active Management/p div class=photogrid div class=photoitem itemprop=employees itemscope itemtype=http://schema.org/Person; itemref=GL img itemprop=image src=/images/GJGL.jpg alt=Gavin Lawrie - Managing Director div itemprop=nameGavin Lawrie/div div itemprop=jobTitleFounder amp; Managing Director/div /div !-- more employees -- /div div id=bio-display itemscope div class=bio-text id=GLdl dtGavin Lawrie: Founder amp; Managing Director/dt dd itemprop=descriptionGavin is .../dd /dl/div !-- more employees -- /div /div The ugly: div id=bio-display itemscope. That itemscope is there only to prevent the description property of the Person from applying to the organization, and does so because the algorithm to crawl the properties of an item stops at itemscope. This is a silly hack, because it is not an item, and I don't expect many people would find this solution even if they knew about the problem. Have others encountered this problem and how did you deal with it? Should we have yet another property like itemunscope that stops the crawl algorithm but does not create a new item? Could we tweak the validity definitions so that this kind of thing would cause validators to complain, or should we leave it completely to vocabulary-specific validators to spot this kind of thing? (They can't if they operate on the microdata level and not DOM level, which I think they should.) Sorry for the lack of solutions in this mail, but I though it was worth raising anyway. (One idea of mine that was discussed some time ago was to only let each property belong to one item, letting items steal each others properties by use of itemref. Even though it would solve this particular problem, it is quite weird and was rightfully rejected.) -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Session Management
Op vrijdag 10 juni 2011 19:36:15 schreef u: On 10/06/2011, at 4:23 PM, Dave Kok wrote: Ultimately a user-agent must use whatever method required by the server not the method defined by the author. A user- agent can transparently find out which method to use with a HEAD request. Or if transport layer security is used simply guess one and see if it works and try again if it doesn't. I'm not sure i agree. The server has served up the page so ultimately it is in control. If the author specifies something which the server can not handle, that's just an authoring bug is it not? I also don't think an agent should be making any guesses...this would definitely seem to violate the authority to define the modus operandi. This is assuming the form's action targets the same domain. I see no reason why it should. On top of that authentication is a protocol thing so it's best to leave most of the details at that level and not expose those to a higher level. As rational you can look at the XMLHttpRequest.open function. It only allows an author to supply a username and password and not what method to use or any additional parameters. But, it also allows for manually setting the Authorization header which takes precedence over the method arguments. Really, never tested that, could be interesting. What do you mean by it's a protocol thing? The idea is to provide a UI to enable a human to interact with the protocol, this must be present in some way, either by the UA as at present, or through forms as suggested. Personally I prefer the perspective that you are providing a UI for the use case 'to log in', not to give access to the protocol. If you limit it to a use case without knowledge of the protocol you also allow for broader implementation. For instance when the HTTP protocol isn't used. Using forms as suggested I fully support. But my preference is to limit the forms to gathering the information needed to login and let a user-agent worry about the details. I would expect that the only information required is the user's credentials and perhaps a domain (never fully read up on digest authentication). If you disagree then I am afraid we have to settle on this by agreeing that we disagree. Also binding the username and password input fields to the authorization header should properly not be done by reserving names in the name attribute of the input field. I would suggest using a special purpose attribute like authorization to declare their binding. Otherwise authors have to cope with reserved names which is properly unacceptable backwards-compatible wise. form method=get action=/resource authorize !-- use custom http header-- input type=header name=Language value=en_US input type=text authorization=username input type=password authorization=password input type=submit value=load /form -- Dave Kok But, in reference to backwards compatibility, the authorization must be explicitly declared so this wouldn't be applied universally. Yes but browsers not supporting the new feature would simply post the username and password without using any authentication method. However those fields are suppressed if no the name attribute isn't used. Thus using a new attribute has my preference. Also to allow building a work around for non-conforming browser which will exists for many years to come even is this feature finds it way into the spec. But, the authorization would only be applied when instructed through the application of the specific header. Yes indeed. This means that there can't be any conflict with existing pages\forms as form headers don't currently exist. I can't determine the validity of the claim. That in itself worries me. I you are right I would agree. Personally I would take the safe road. There is a benefit to binding the parameters from input names - for old browsers which don't support the new headers they will at least send a request to the server which can be setup to handle legacy requests as form encoding, probably falling back to setting up a cookie session. As you noted, if new attributes are introduced, no data will be sent. The problem is that by binding it on the name attribute, authors no longer have a choice. Binding on a new attribute gives authors a choice. They can either choose to include both a name attribute and the new attribute for binding and things are as you commented. Or authors can use a different approach. What worries me is that if a author does not account for user-agents not handling the authorization, the user's credentials are sent in the clear for all the see, especially when using the GET method. By giving authors the choose you also force them to think it over. At least to some degree. Those that just copypaste stuff will properly never think it over. But disregarding those if authors have to choice those not accounting for the user
Re: [whatwg] window.cipher HTML crypto API draft spec
On Tue, 2011-05-24 at 07:48 -0700, David Dahl wrote: Consider for example a DropBox-style service that has a browser-based UI but that has a design where content is encrypted on the client-side so that the service provider is unable to decrypt the data. In this case, it would make sense to be able to implement a file download by having a plain a href to an excrypted file and have the browser automatically decrypt it. Likewise, a service that allows the transmission of encrypted images should be implementable by having img src point directly to an encrypted file. I think someone was asking about that kind of functionality during my presentation at Mozilla. Again, this would be a pretty advanced complement to this API - I would love to see something like that spec'd and implemented as well. My main worry is that if the two ways of doing crypto don't appear at the same time for Web authors to use, the Web will shift in an unfortunately hashbangy direction. I suggest adding a Content-Encoding type that tells the HTTP stack that the payload of a HTTP response is encrypted and needs to be decrypted using a key previously initialized using the JS API. cool. I'll look into that. Thanks. On the other hand, it seems that letting Web apps generate per-user key pairs and letting Web apps discover if the user possesses the private key that decrypts a particular message is a privacy problem. Someone who wishes to surveil Web users could use private keys as supercookies, since the generated private key is most probably going to be unique to user. Currently, my implementation requires the enduser to open a file from the file system in order to view the contents of the private key. It is only accessible to privileged code - content has no access to it whatsoever. I didn't expect content to have access to the key bits per se. I expected Web content-provided JS to be able to encrypt and decrypt stuff with a key it has asked the browser to generate (if the user has authorized the origin to use the crypto API). The ability to decrypt or encrypt a message with a particular private key is proof of possession of that key, so users in possession of a particular key could be tracked. This could be mitigated by granting the crypto permissions to a pair of origins: the origin of the top level frame combined with the origin that wants to access the API. This way iframed Web bugs could track the user across sites after having once obtained a crypto permission for their origin. See http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf Currently, it is unfortunate that choosing to use a webmail client effectively prevents a person from using encrypted email. To allow people to use end-to-end encrypted email with webmail apps, it would be useful to support OpenPGP as an encryption format. (Obviously, a malicious webmail app could capture the decrypted messages on the browser and send them back to the server, but when the webmail app itself doesn't contain code like that, putting the decryption in the browser rather than putting it on the server would still probably be more subpoena-resistant and resistant against casual snooping by bored administrators.) I think with an API like this we might see a whole new breed of communications applications that can supplant email and webmail entirely. Maybe. But Google Wave flopped and email is still here. I think it would be good to design for the ability to plug into email's network effects instead of counting on a new breed of communication making email irrelevant. The public key discovery section shows a /meta end tag. I hope this is just a plain error and having content in a meta element isn't part of any design. The tag is unimportant as well - can you explain why you hope this wil not use a meta tag? A meta tag can be used if there's no need for the meta element to have child nodes. You can't make a meta element have child nodes or an end tag. I could just as easily use addressbookentry You can't introduce an addressbookentry element as a child of the head element. The result would not degrade gracefully. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
On 14 June 2011 08:32, Ian Hickson i...@hixie.ch wrote: On Thu, 10 Mar 2011, Jukka K. Korpela wrote: Under these circumstances, what should we say to people to need to use paragraphs that contain lists, for example? That paragraphs don't contain lists; when a sentence has * this * structure, ...it is in fact two paragraphs and a bullet list. I think that's an opinion, not a fact. Indeed, but block of text is pretty much what a paragraph is -- it isn't a logical construct. Cite? The Oxford English Dictionary would seem to disagree with you: A distinct passage or section of a text, usually composed of several sentences, dealing with a particular point, a short episode in a narrative, a single piece of direct speech, etc. It's quite possible, if rare, for a sentence to span paragraphs even without lists being involved... Take, for instance, the first... ...no, the second... ...no, the third, of these blocks of text. That sentence spans three paragraphs. My view is that that's one paragraph, with line breaks. Consider: I like apples, pears, grapes, but not bananas. Nor do I like peaches. and: I like * apples * pears * grapes but not bananas. Nor do I like peaches. The difference between those two is presentational, not semantic. Each is a single paragraph. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Nullable types and MediaStreams
On 2011-06-14 09:05, Ian Hickson wrote: Thanks to Cameron's fantastic work, this is fixed now, so there should no longer be a need for reading between the lines. Please let me know if it's still ambiguous, though. Thank you Cameron. Maybe the null-check in step 3 under When the PeerConnection() constructor is invoked .. should not be there anymore since signalingCallback is not nullable. //Per-Erik
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
On Tue, Jun 14, 2011 at 2:04 AM, Markus Ernst derer...@gmx.ch wrote: Am 14.06.2011 09:32 schrieb Ian Hickson: On Fri, 11 Mar 2011, Markus Ernst wrote: Consider this markup of Andy's use case: pI always like to eat these cheeses: il iliCheddar/ili, iliStilton/ili, and iliRed Lester/ili, /il but I enjoy them most with one of these biscuits: il iliwheat crackers/ili, ilirye crackers/ili, ilidigestives/ili, /il and some chutney./p il stands for inline list,ili for inline list item (it's a pity we can't reuseli for BC reasons). Conforming UAs would be required to ignore any content in anil element, except it is in anili element. Like that, the above example would be perfectly readable in legacy UAs, but make sense in HTML5-capable UAs. It would even be easy to stlye the output for legacy UAs supporting display:list-item, as this example illustrates: http://www.markusernst.ch/stuff_for_the_world/list-test.html What problem does this solve? It solves the first use case Jukka mentioned in his original post: Am 10.03.2011 09:20 schrieb Jukka K. Korpela: The p element (ever since it became an element) has always allowed inline (text-level) content only, and no change is planned to this in HTML5. Under these circumstances, what should we say to people to need to use paragraphs that contain lists, for example? So does Hixie's answer of Tell them to use two ps and a ul. His answer has the benefit of not requiring any changes to HTML, and not introducing a fourth type of list that is only very subtly different from ul. On Tue, Jun 14, 2011 at 7:22 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: Consider: I like apples, pears, grapes, but not bananas. Nor do I like peaches. and: I like * apples * pears * grapes but not bananas. Nor do I like peaches. The difference between those two is presentational, not semantic. Each is a single paragraph. Well, in standard English, the prose list would actually read I like apples, pears, and grapes, but not bananas.. You'd have to somehow mark up and hide the and when presenting it as a structured list instead of a prose list. This suggests that there *is* a semantic difference between the two. It's a subtle difference, to be sure, but it's there. More importantly, what problem is caused by having to mark up those two cases slightly differently? ~TJ
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
On 6/14/11, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jun 14, 2011 at 2:04 AM, Markus Ernst derer...@gmx.ch wrote:
Consider:
I like apples, pears, grapes, but not bananas. Nor do I like
peaches.
and:
I like
* apples
* pears
* grapes
but not bananas. Nor do I like peaches.
The difference between those two is presentational, not semantic. Each
is a single paragraph.
Well, in standard English, the prose list would actually read I like
apples, pears, and grapes, but not bananas.. You'd have to somehow
mark up and hide the and when presenting it as a structured list
instead of a prose list. This suggests that there *is* a semantic
difference between the two. It's a subtle difference, to be sure, but
it's there.
The difference isn't semantical. I'm not educated about archaic
English, but in my language, all items were seperated by an ok, as
in eppli ok perur ok greip but nowadays the norm is to somehow
hide all the oks but the last one (probably for brevity). HTML has
more structure, and can nest lists without ambiguity, so the and is
unnecessary.
However, if rendering lists inline, and thereby loosing this
structural nature of lists is desired, it's the job of CSS.
ul
liapples
lipears
ligrapes
/ul
but not bananas.
With the following stylesheet:
ul { display: inline; }
ul li :after { content: ', '; }
ul li:last-child :before { content: 'and'; }
ul li:last-child :after {content: '';}
Re: [whatwg] behavior when typing in contentEditable elements
On Mon, Dec 21, 2009 at 1:21 PM, Ojan Vafai o...@chromium.org wrote:
Dealing with inconsistencies in browser behavior during typing is one of the
hardest parts of writing a sane web-based rich-text editor. We have
researched what a variety of text editors (Word, Powerpoint, Wordpad,
TextEdit) and browsers using contentEditable/DesignMode currently do when you
press different keys on the keyboard, in a number of rich text situations,
with a variety of text selections. From this data, we attempt to identify
recommendations that are OS-agnostic for editing behaviors inside a
contentEditable element.
Since we've used a bunch of tables and formatting, we've attached the doc as
an HTML file in addition to inline.
I've recently been working on specs for some of this stuff,
specifically Enter and Backspace. I'm not yet done, but here's what I
have so far:
http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements
I've defined the delete command to be the same as Backspace. For
Enter, you recommend making some commands splitBlock, splitOutOfBlock,
and insertBreak, but none of these seem to be supported by any
browser. I used the insertParagraph command to have the meaning of
hitting Enter, because WebKit and Opera already behave that way, and
IE's and Gecko's behavior for insertParagraph is not useful. (WebKit
does seem to support an insertLineBreak command that I assume behaves
like Shift-Enter.)
You can see an experimental implementation of the spec's
delete/insertParagraph commands (along with others) here:
http://aryeh.name/spec/editcommands/autoimplementation.html
Run tests for a command will tell you what the spec implementation
and the current browser do when the command is run on a variety of
inputs. You can also add your own inputs, with [] marking selections
in text nodes and {} in elements. Ignore any notes asking you whether
to store new test results. There are also manual tests that let you
compare the specified behavior for the command to the behavior of
browsers when you actually hit the relevant key:
http://aryeh.name/spec/editcommands/linebreaktest.html
http://aryeh.name/spec/editcommands/backspacetest.html
I largely agreed with and followed the recommendations in the paper,
and some were quite helpful. Some points of difference:
* It's not clear what behavior you recommend for delete if the cursor
is collapsed at the beginning of the first item of a list. I wound up
outdenting the first item in that case, which doesn't really match
anyone's behavior but seems like the most sensible option given how
lists work in HTML.
* You didn't mention what to do for delete if the cursor is collapsed
at the beginning of an indented block (blockquote). I outdent the
block, matching word processors but not browsers (which merge with the
previous block).
* If the cursor is collapsed immediately after a list whose last item
is empty, you suggest removing the last item on delete. Word 2007
seems to merge into the last item instead, as do browsers. That makes
more sense to me, and it's simpler, so it's what I specced.
* When hitting Enter in a blockquote, you suggest splitting the
blockquote. I disagree: blockquote is meant to contain block
content, and the intent in such a case is likely to have multiple
paragraphs within the same blockquote. I've specified that the
contents should be split, not the blockquote itself.
* I haven't yet specified that id's should not be duplicated, but I plan to.
You suggest that the tab key in browsers should act like indent, as in
dedicated text editors. This isn't tenable -- it means that if you're
using Tab to cycle through focusable elements on the page, as soon as
it hits a contenteditable area it will get stuck and start doing
something different. No current browser does this, for good reason.
I plan to specify forwardDelete (= Delete key) next, followed by
insertText (= typing characters) and maybe insertLineBreak (=
Shift-Enter). Then I'll move on to copy/cut/paste and undo/redo.
Then I'll most likely do queryCommand*(). At some point I'll probably
also do more work on Selection, such as specifying Selection.modify()
and requiring that user actions behave like it. At that point I'll
have specified pretty much all the major behavior of editable areas
and execCommand(), as far as I'm aware, and I'll move on to doing
cleanup and refinement.
Re: [whatwg] input element's value should not be sanitized during parsing
On Fri, 11 Mar 2011, Jonas Sicking wrote: On Tue, Dec 28, 2010 at 11:46 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 20 Sep 2010, Mounir Lamouri wrote: With the current specification, these two elements will not have the same value: input value=foo#13;bar type='hidden' input type='hidden' value=foo#13;bar Yes they will. The attribute order has no effect. Elements are created by the parser with their attributes already set: # When the steps below require the UA to create an element for a token in # a particular namespace, the UA must create a node implementing the interface # appropriate for the element type corresponding to the tag name of the # token in the given namespace (as given in the specification that defines # that element, e.g. for an a element in the HTML namespace, this # specification defines it to be the HTMLAnchorElement interface), with # the tag name being the name of that element, with the node being in the # given namespace, and with the attributes on the node being those given # in the given token. -- http://www.whatwg.org/specs/web-apps/current-work/complete.html#create-an-element-for-the-token Except that I don't think this is how any implementation actually works. Nor do I have any desire to write the implementation this way since it means duplicating a lot of code. I'd have to add code which implemented attribute behavior both in some special code path triggered during element creation, as well as code to react to attribute changes triggered by attribute changes in setAttribute/removeAttribute. So far this hasn't been needed and the parsing code basically just calls setAttribute. Unless there are really good reasons to change this I'd like to avoid it. So far I haven't heard of any such reasons. The spec is defined such that attribute setting during element creation is order-agnostic. I believe this is consistent with what authors expect (in part based on the confusion I've seen when authors run into cases where that isn't the case). How you implement that is somewhat orthogonal to how it is specced; if there are specific things that are hard to implement, I'm happy to discuss them specifically if you like. On Tue, 21 Sep 2010, Boris Zbarsky wrote: Where does it say that it's atomic? �I don't see that anywhere (and in fact, the create an element code in the Gecko parser is most decidedly non-atomic). �Now maybe the spec intends this to be an atomic operation; if so it needs to say that. The operation it describes is a single operation: create a node. It describes various constraints on that operation, one of which is that the node have the various tokenised attributes set. I don't understand how creating a node could be anything other than atomic -- either it exists or it does not. You're expecting several operations to happen at the same time. We could certainly manually insert the attributes and their value into the datastructure inside the element which stores the attribute name/value pairs. However at some point we need to update all of the state that these values drive. Things like sticking elements into id-hashes, storing the calculated type of an input, calculating the effective URI of an image, etc. This involves several separate pieces of state and so can't happen all at the same time. Sure. When those things happen is defined by the spec too. On Tue, 21 Sep 2010, Jonas Sicking wrote: Also, it would mean that the following two pieces of code behaves differently: inp = document.createElement(input); inp.setAttribute(value, foo\nbar); inp.setAttribute(type, hidden); and inp = document.createElement(input); inp.setAttribute(type, hidden); inp.setAttribute(value, foo\nbar); This does not seem desirable. I can't argue that it's desireable, but it's how the Web works, as I understand it. Gecko doesn't exhibit this behavior and I don't know of any sites that doesn't work in Gecko because of this. On Wed, 30 Mar 2011, Mounir Lamouri wrote: FWIW, it does. The first inp.value is 'foobar' while the second is 'foo bar'. See: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/900 Though, I do not think this is related to the initial issue which is about setting attributes while creating the element from the parser. Right, the behaviour is different when the parser does it. This is per spec, and seems to match what Firefox does. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] selection-related IDL attributes and methods and input type
On Mon, 14 Mar 2011, Mounir Lamouri wrote: Currently, the specs say that select(), selectionStart, selectionEnd and setSelectionRange() only apply to the input element when the type is text, search, url, telephone or password. Obviously, they should also apply when type is email [1]. [1] See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12262 I don't think it's obvious, as noted in that bug. :-) But, I'm wondering what should be done for types that should come with a widget like date, datetime, datetime-local, time, week, month, number, range or color. The resulting widget might have a text field. That's even very likely for all time-related and number types. Should those IDL attribute and methods apply in that case and be used on the text field? or should we just ignore them? Or maybe, we could have them apply depending on the UA's widget and not raise an exception when they do not apply [2] and do nothing instead? [2] Actually, that's another issue but I wonder why we raise an exception... What is the use case here? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. - WBR, Alexey Proskuryakov
[whatwg] Idea: pseudo-classes :valid and :invalid for whole form?
We already have required attribute and :valid plus :invalid classes,
which are nice. However some may want to display additional warning
when form wasn't filled correctly. Just some single warning, not
specific field-related. Could you consider adding form element class
for such a purpose?
Example:
p id=errYou've to fill all required fields/p
form:invalid #err {
display: block;
}
--
Rafał
Re: [whatwg] data: URI origin
On Mon, 14 Mar 2011, Luis Marsnao wrote: I'm attempting to write a client-side script that processes a user selected file through an input element. Since the input element interface conceals the file: URI, the best solution I can think of is to access the file through the input element's interface, get its data: URI through readAsDataURL in FileAPI's FileReader interface, and process the data: URI. However, I get not-same-origin errors when I try to use this URI. Specifically, this happens when I try to use XMLHttpRequest to retrieve an XML resource with the data URI. With XHR, yes, that's normal, as I understand it. You can't usefully use XHR with data: URLs. With iframes you should be able to read the content. Is there a better way to process files in a client-side script? I considered using blob: URIs, but the support is not yet there. FileReader is the way you're supposed to do it from a File object. http://dev.w3.org/2006/webapi/FileAPI/#FileReader-interface Since you have a data: URL, you could also just decode the data: URL yourself. It contains all the data. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Nullable types and MediaStreams
Per-Erik Brodin: Maybe the null-check in step 3 under When the PeerConnection() constructor is invoked .. should not be there anymore since signalingCallback is not nullable. Yes, that step’s not necessary any more. -- Cameron McCormack ≝ http://mcc.id.au/
[whatwg] CSS5 anyone? Or a WHATWG CSS3 Working Group would be cool too
On Sat, 19 Mar 2011, Martin Alterisio wrote: I hope I'm not stepping on a tabooed topic here... It's just that I wish that someone would do to CSS what you guys did to HTML. I respect the work being done by the W3C CSS Working Group but it just doesn't fell enough. It doesn't feel open enough, nor fast enough. I really want to see a version of CSS where the language provides a straightforward solution to layout rather than a challenge. But I don't see it happening with just the efforts and the current structure that supports CSS development. Is there anything that can be done about this? On Sun, 20 Mar 2011, David Singer wrote: You could help the CSS group move faster? They (we) are nice people, with a large list of things to work on. There's even a public mailing list. If you have ideas, they are pretty open to them, also. Before you give up, I'd give them a try. On Sun, 20 Mar 2011, Boris Zbarsky wrote: Just to note, what the CSS WG most needs right now as far as I can see is not blue-sky ideas; there are plenty of those floating around. What's needed is firming up the basis for the existing specifications (e.g. doing something about the underdefined mess that is the CSS 2.1 box model), the way HTML5 actually specified things that HTML4 specified. Also writing tests. Lots of tests. Since the CSS working group is actively working on CSS, it would be rahter inappropriate for us to do something like that. As Dave says above, I would encourage you to engage with the working group directly. I do agree that it'd be nice if the CSS specs could be rewritten in the style we've used for HTML, though, but that would be a huge amount of work and I don't know anyone who has the bandwidth to do it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input element's value should not be sanitized during parsing
On Tue, Jun 14, 2011 at 2:00 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 Mar 2011, Jonas Sicking wrote: On Tue, Dec 28, 2010 at 11:46 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 20 Sep 2010, Mounir Lamouri wrote: With the current specification, these two elements will not have the same value: input value=foo#13;bar type='hidden' input type='hidden' value=foo#13;bar Yes they will. The attribute order has no effect. Elements are created by the parser with their attributes already set: # When the steps below require the UA to create an element for a token in # a particular namespace, the UA must create a node implementing the interface # appropriate for the element type corresponding to the tag name of the # token in the given namespace (as given in the specification that defines # that element, e.g. for an a element in the HTML namespace, this # specification defines it to be the HTMLAnchorElement interface), with # the tag name being the name of that element, with the node being in the # given namespace, and with the attributes on the node being those given # in the given token. -- http://www.whatwg.org/specs/web-apps/current-work/complete.html#create-an-element-for-the-token Except that I don't think this is how any implementation actually works. Nor do I have any desire to write the implementation this way since it means duplicating a lot of code. I'd have to add code which implemented attribute behavior both in some special code path triggered during element creation, as well as code to react to attribute changes triggered by attribute changes in setAttribute/removeAttribute. So far this hasn't been needed and the parsing code basically just calls setAttribute. Unless there are really good reasons to change this I'd like to avoid it. So far I haven't heard of any such reasons. The spec is defined such that attribute setting during element creation is order-agnostic. I believe this is consistent with what authors expect (in part based on the confusion I've seen when authors run into cases where that isn't the case). How you implement that is somewhat orthogonal to how it is specced; if there are specific things that are hard to implement, I'm happy to discuss them specifically if you like. The problem, if I understand things correctly, is that setAttribute is *not* order agnostic, while the parsing code is expected to be. This means that we can't use the same code paths for setAttribute and parsing. This is not acceptable to us in Gecko. We're not willing to have two code paths for setting attributes. / Jonas
Re: [whatwg] input element's value should not be sanitized during parsing
On Tue, 14 Jun 2011, Jonas Sicking wrote: The problem, if I understand things correctly, is that setAttribute is *not* order agnostic, while the parsing code is expected to be. This means that we can't use the same code paths for setAttribute and parsing. You can, you just have to have a special initialisation signal that the parser sends to an element after its set its attributes. This is not acceptable to us in Gecko. We're not willing to have two code paths for setting attributes. You already _have_ two code paths. The example you gave shows that the parser is order agnostic but the equivalent DOM code is not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] File API Streaming Blobs
On Mon, 21 Mar 2011, Simon Heckmann wrote: I found this thread (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/02997 3.html) in the archive of this mailing list, but I could not determine if any decision was made whether this should be implemented or not. I am interested in this, because I came up with a scenario which would benefit from Streaming Blobs: I use the File API to locally store larger video files on the users hard drive. For security purposes I encrypted them with AES and use a javascript library for local just-in-time decryption. This is not yet a productive application bur more of a prototype. However, I experienced javascript manipulation of large data can be quite slow so we do not want the user to wait until the full video is decrypted/manipulated. Therefore I would vote for a way to append data to a Blob and the ObjectURL reflects these modifications. Maybe something like createStreamableObjectURL could be used for differentiation? Just wanted to express my thoughts because I think the whole File API is a great idea! I recommend forwarding your suggestion to the W3C public-weba...@w3.org mailing list, which is where discussion of the File API specs more usually takes place. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why do we need Mozilla in userAgent string?
On Sat, 26 Mar 2011, Biju wrote: Nearly all browsers have word Mozilla in userAgent string, hence no benefit in detecting that at server. So why do we need Mozilla in userAgent string? On Sat, 26 Mar 2011, Oliver Hunt wrote: Because there are a huge number of sites out there that check for the existence of a feature by doing 'navigator.userAgent.indexOf(mozilla) != -1' or similar (or they decide that the absence of the mozilla term means that you're IE6), so not including the word mozilla in the user agent would cause those sites to break. The majority of the content in modern user agent strings is not about telling the server or client anything useful about the browser, it's about making badly written websites work correctly. Yup, that's pretty much it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Time Parsing
On Mon, 28 Mar 2011, Lachlan Hunt wrote: The algorithm to parse a time component contains a bug. When parsing the seconds, the spec states: Collect a sequence of characters that are either characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) or U+002E FULL STOP characters. If the collected sequence has more than one U+002E FULL STOP characters, or if the last character in the sequence is a U+002E FULL STOP character, then fail. Otherwise, let the collected string be second instead of its previous value. This is incorrect because it allows the second component to contain more than 2 digits before the decimal point. i.e. 00:00:012.345 would parsed without error. Fixed. This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
