Re: [whatwg] Decimal comma in numeric input
Aryeh Gregor wrote: On Sat, Apr 16, 2011 at 9:18 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: An element for user input of a real number in a format that uses a suitable decimal separator is hardly a specific need. It's more specific than just an element for user input of a number. This isn't a matter of being more or less specific. It's about adequacy of a concept and acceptability of implementations. Formally, one might say that specifications can define just the internal format and leave the rest to implementors, but that's not a reasonable approach. The current specification is perfectly sufficient for many use-cases -- at a minimum, English-language sites. My original observation was that Google Chrome accepts a number with decimal comma. It does that quite independently of the language. As far as specifications go, it could just as well _only_ accept decimal comma. Would that be perfectly suitable? If there's author demand for control over decimal separators, a new CSS property is probably the right way to do it, No, this is not about optional presentational suggestions concerning the rendering of documents. It's about processing of input data. Something that allows the author to specify what decimal separator is used would certainly be more features. I wasn't saying that authors should be able to specify what decimal separator is used. I discussed the need for addressing the decimal separator issue and at least specifying _how_ it is decided on. Then authors would know what to expect when they use input type=number. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
Dne Fri, 15 Apr 2011 23:56:45 +0200 Aryeh Gregor simetrical+...@gmail.com napsal(a): 2011/4/14 Oldřich Vetešník vetes...@mrmil.cz: I am afraid that if the decimal separator (in rendering) doesn't behave the way people expect it to, it will mean web developers will have to deal with clients saying We wan't to be able to enter a comma. The dealing might mean not using input type=number at all, which is something we might not want... I didn't read the whole thread, but: authors with specific needs will always want to roll their own inputs for most of these things, and that's fine. If input type=number satisfies 80% of the use-cases, that's fine. As more authors start using the new input types, we'll get feedback about what the most-requested features are, and we can consider adding them at that time. Trying to add more features to the new form stuff is premature when we only have one really good implementation (IMO: Gecko's), and that implementation is partial. The time to talk about new features is when we have some amount of stability and interoperability in existing features. Indeed, good point. Let's wait and see. Ollie
Re: [whatwg] How to handle multitrack media resources in HTML
Hey Ian, all, Sorry for the slow response .. There's a big difference between text tracks, audio tracks, and video tracks. While it makes sense, for instance, to have text tracks enabled but not showing, it makes no sense to do that with audio tracks. Audio and video tracks require more data, hence it's less preferred to allow them being enabled but not showing. If data wasn't an issue, it would be great if this were possible; it'd allow instant switching between multiple audio dubs, or camera angles. I think we mean different things by active here. The hidden state for a text track is one where the UA isn't rendering the track but the UA is still firing all the events and so forth. I don't understand what the parallel would be for a video or audio track. The parallel would be fetching / decoding the tracks but not showing them to the display (video) or speakers (audio). I agree that, implementation wise, this is much less useful than having an active but hidden state for text tracks. However, some people might want to manipulate hidden tracks with the audio data API, much like hidden text tracks can be manipulated with javascript. Text tracks are discontinuous units of potentially overlapping textual data with position information and other metadata that can be styled with CSS and can be mutated from script. Audio and video tracks are continuous streams of immutable media data. Video and audio tracks do not necessarily produce continuous output - it is perfectly legal to have gaps in either, eg. segments that do not render. Both audio and video tracks can have metadata that affect their rendering: an audio track has a volume metadata that attenuates its contribution to the overall mix-down, and a video track has matrix that controls its rendering. The only thing preventing us from styling a video track with CSS is the lack of definition. Yes, and the same (lack of definition) goes for javascript manipulation. It'd be great if we had the tools for manipulating video and audio tracks (extract/insert frames, move audio snippets around). It would make A/V editing - or more creative uses - really easy in HTML5. Kind regards, Jeroen
Re: [whatwg] microformats, microdata, and custom data attributes
Hi Tab, On Friday 15 April 2011 22:12:24 Tab Atkins Jr. wrote: On Fri, Apr 15, 2011 at 6:29 PM, Justin Karneges jus...@affinix.com wrote: Hi folks, I'm desiring a way to markup mentions of a person semantically within HTML, for use in an open standard. Think of a more rich form of the @person convention used on Twitter and elsewhere: p@justin I totally agree/p My first thought was to use a data-* attribute. For example: pa href=http://example.org/justin/; data-mention- id=acct:jus...@example.org data-mention-context=replyjustin/a I totally agree./p However, the HTML specification says custom data attributes are only to be used privately. So, I am not sure if it is appropriate to create a public standard whereby independent developers are encouraged to utilize a common data-* attribute. Another way is to use Microdata, though I seem to have to hack it a bit to have hidden values: pa href=http://example.org/justin/; itemscope itemtype=http://example.org/itemtypes/mention; itemid=acct:jus...@example.orgspan itemprop=context:reply/span itemprop=namejustin/span/a I totally agree./p If necessary, representing hidden data can be done via meta itemprop content in Microdata. It might be useful to understand a little more about your goal in marking this up, though, so the most appropriate way to do so can be determined. Is this meant to be processed by machines? If so, what use will it be put to? Yes, this is meant to be processed by machines, as part of a data exchange protocol. It is not browser-specific. For example, this kind of HTML formatting may find its way into an Atom feed, or even an XMPP message. It is not expected that this format would be shoved directly to a browser for render (although, if someone does that, ideally it should degrade gracefully, hence the use of a around the name). Here are two things I'd expect apps to do: 1) Render the mentions in a special way. For example, our application shows the mentioned name inside of a colored, button-looking box with an icon image based on the domain of the person being mentioned. This kind of presentation- level detail would not be encoded in the HTML itself. 2) Keep display names up to date. In the event that a user changes his/her name, but the account id is not changed, future replays or retransmissions of this HTML may contain different name text (the 'justin' part in my example). For example, an aggregator may track name changes, and update its cached HTML accordingly rather than holding onto stale names. Regarding #2, it may also be useful for servers that persist this data to do so without saving any name text at all (imagine the 'a' element in the earlier example having no cdata). Whenever the HTML blob is extracted from the db, it would need to be stamped with the name of the mentioned user before sending out to a client. So I take it that using data-* for this is not recommended? Justin
Re: [whatwg] microformats, microdata, and custom data attributes
Hi Ashley, On Friday 15 April 2011 23:00:15 Ashley Sheridan wrote: Couldn't the cite attribute be made use of the q, blockquote and cite tags? It only really allows the source to be specified for a quote/citation, so maybe some other semantic attribute that lends itself well to other information, like your context example? Do you suggest using microdata with these tags then?
Re: [whatwg] microformats, microdata, and custom data attributes
On Mon, Apr 18, 2011 at 11:53 AM, Justin Karneges jus...@affinix.com wrote: Hi Tab, [snip] So I take it that using data-* for this is not recommended? Yes, data-* isn't intended to be used for interchange information and the like. It's just a blessed way for scripts to stash data onto DOM nodes directly, in situations where that's the most convenient place to put the data. On Friday 15 April 2011 22:12:24 Tab Atkins Jr. wrote: On Fri, Apr 15, 2011 at 6:29 PM, Justin Karneges jus...@affinix.com wrote: Hi folks, I'm desiring a way to markup mentions of a person semantically within HTML, for use in an open standard. Think of a more rich form of the @person convention used on Twitter and elsewhere: p@justin I totally agree/p My first thought was to use a data-* attribute. For example: pa href=http://example.org/justin/; data-mention- id=acct:jus...@example.org data-mention-context=replyjustin/a I totally agree./p However, the HTML specification says custom data attributes are only to be used privately. So, I am not sure if it is appropriate to create a public standard whereby independent developers are encouraged to utilize a common data-* attribute. Another way is to use Microdata, though I seem to have to hack it a bit to have hidden values: pa href=http://example.org/justin/; itemscope itemtype=http://example.org/itemtypes/mention; itemid=acct:jus...@example.orgspan itemprop=context:reply/span itemprop=namejustin/span/a I totally agree./p If necessary, representing hidden data can be done via meta itemprop content in Microdata. It might be useful to understand a little more about your goal in marking this up, though, so the most appropriate way to do so can be determined. Is this meant to be processed by machines? If so, what use will it be put to? Yes, this is meant to be processed by machines, as part of a data exchange protocol. It is not browser-specific. For example, this kind of HTML formatting may find its way into an Atom feed, or even an XMPP message. It is not expected that this format would be shoved directly to a browser for render (although, if someone does that, ideally it should degrade gracefully, hence the use of a around the name). Here are two things I'd expect apps to do: 1) Render the mentions in a special way. For example, our application shows the mentioned name inside of a colored, button-looking box with an icon image based on the domain of the person being mentioned. This kind of presentation- level detail would not be encoded in the HTML itself. 2) Keep display names up to date. In the event that a user changes his/her name, but the account id is not changed, future replays or retransmissions of this HTML may contain different name text (the 'justin' part in my example). For example, an aggregator may track name changes, and update its cached HTML accordingly rather than holding onto stale names. Regarding #2, it may also be useful for servers that persist this data to do so without saving any name text at all (imagine the 'a' element in the earlier example having no cdata). Whenever the HTML blob is extracted from the db, it would need to be stamped with the name of the mentioned user before sending out to a client. Okay, so it's intended as basically RSS for tweets - a distributed way of marking of mini-conversation streams so arbitrary endpoint applications can consume and reformat them? Got it. First, I recommend working with the Microformats community to define the data language. If this is meant to be a standard, they're the go-to people to work with in getting this sort of thing stable and complete. This is roughly similar to hAtom, which is for marking up blogs and similar, but it has a further element of replying or mentioning which is somehow tied up in identity management. There's some difficult issues hiding in here that probably need a bunch of eyes to find bugs. Microformats are traditionally defined using HTML4 rel/class-based techniques, but they're trivial to translate into a more explicit Microdata-based vocabulary as well. ~TJ
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On Tue, Apr 12, 2011 at 5:18 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. Our list currently includes: * http: * https: * ftp: * file: * about: * data: Email specific schemes: * cid: * mid: Scripting schemes: * javascript: * vbscript: Ancient Netscape scripting schemes. some were apparently aliases for javascript: * mocha: * livescript: * livewire: * tcl: Also, implementers need to be take care with vendor specific schemes: * chrome: (Mozilla, Chrome) * view-source: (Mozilla, Chrome) * res: (IE) * resource: (Mozilla) * opera: (Opera) * attachment: (Opera) (This list is probably incomplete) We'd like to know if we've missed any important schemes that must be blocked, and we think it might be useful if the spec listed most of those, except for the vendor specific schemes, which should probably be left up to each vendor to worry about. possibly mthml: (Windows) I should go fish for a list sometime. Poke me in two weeks?
[whatwg] Cache Manifest: why have FALLBACK?
This is a reply to an old discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023137.html Now, I haven't probably thought this enough, but could the FALLBACK and NETWORK be combined into one NETWORK? Both are doing pretty much the same thing after all? Here's how it would work: NETWORK: item [optional-fallback-item] More specific entries would take precedence, i.e. /file.html would be more important than /file or / or * ... Example: NETWORK: * / /offline /file.html /offline-for-file.html This way - * would map like it does in the current spec - / /offline would map like it does in the FALLBACK section/current spec and would take precedence over * because it's more specific over ** - /file.html /offline-for-file.html would take precedence over all of these. Benefits: Making things simpler, easier for the programmer to understand. Faster to learn, less bugs, better code? Ilkka
Re: [whatwg] microformats, microdata, and custom data attributes
On Monday 18 April 2011 12:48:27 Tab Atkins Jr. wrote: First, I recommend working with the Microformats community to define the data language. If this is meant to be a standard, they're the go-to people to work with in getting this sort of thing stable and complete. This is roughly similar to hAtom, which is for marking up blogs and similar, but it has a further element of replying or mentioning which is somehow tied up in identity management. There's some difficult issues hiding in here that probably need a bunch of eyes to find bugs. Microformats are traditionally defined using HTML4 rel/class-based techniques, but they're trivial to translate into a more explicit Microdata-based vocabulary as well. Given that it is meant primarily as a data exchange protocol, explicit is better, so I'm preferring Microdata instead of Microformats here. Also, it seems Google already has a registry of formats, and one is Person which may be reusable. Now we have this: p span itemscope itemtype=http://data-vocabulary.org/Person; itemid=acct:jus...@example.org meta itemprop=context content=reply/ a itemprop=url href=http://example.org/justin/;span itemprop=namejustin/span/a /span I totally agree. /p We are still debating whether it makes sense to add context in here, but that discussion is not necessary for this mailing list. Thanks for your help in pointing me in the right direction. Justin
