- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 27 Oct 2014 20:41:30 +0000 (UTC)
- To: whatwg@whatwg.org
On Fri, 24 Jan 2014, Jukka K. Korpela wrote:
> 2014-01-22 2:28, Ian Hickson wrote:
> > On Tue, 3 Dec 2013, Jukka K. Korpela wrote:
> > >
> > > Thank you for the clarifications. I may have been stuck to an idea
> > > of a submittable element, possibly adopted from some earlier version
> > > or proposal. I think an explicit short note like "The output element
> > > is not submittable" would be useful.
> >
> > I am reluctant to add that kind of comment for a couple of reasons.
> > First, there's the problem of determining when one would add these
> > notes. Should the spec be explicit about everything it doesn't say?
>
> No, but it should be explicit about things that could easily be
> misunderstood.
Fair enough. I've added some text to this effect.
> > What I would rather do is clarify whatever led to the confusion in the
> > first place. Do you have any idea what it is in the <output> section
> > that might lead you to think that it would be submittable?
>
> Well, it is under the heading "4.10 Forms". As an element for the result
> of some scripted operation (which <output> seems to be meant for),
> <output> need not have anything to do with forms. But when it is under
> "Forms", a natural idea is "oh, this is for some computed value, like a
> total, to be submitted".
In the sentence I added, I added a mention of why there's a relationship
to forms.
> > > (A submittable output element would a natural thing to have in many
> > > cases, e.g. in showing some calculated total to the user and
> > > submitting it along with form data, for checking purposes.)
> >
> > Can you elaborate on this use case? I'm not sure how it would work.
>
> When you calculate the total with JavaScript, mainly to be shown to the
> user, you might as well submit it along with the form, as an extra
> check. If it does not match the total calculated in the server,
> something went very wrong. What you do then is a different question, but
> the important thing is that you detect a problem, instead of charging an
> amount that differs from what the user saw.
Fair enough. You can do this with type=hidden, for what it's worth.
> > The main reason for not submitting it so far has been that it would
> > risk authors relying on the client's computation and thus not doing it
> > on the server,
>
> Authors often rely too much on checks and computations made client-side
> - including new features like @pattern and @required attributes and new
> values of the @type attribute. They have always been able to do that
> with calculated totals, for example - just using an <input> element
> (possibly with @readonly).
Right. But this makes it easier.
> > Without name="", the main purpose of <output> -- making it easy to
> > update non-form-control values in script -- is lost.
>
> The @name attribute in general, except for submittable controls, is
> legacy markup that has caused much confusion. It was introduced long
> ago, before @id was added to HTML, for scripting purposes, on @img and
> @form, as well as on @a for link destinations, but it was unsuitable
> from the beginning. It was not defined to be unique in the document, and
> there have been many attempts to phase out/deprecate/obsolete @name
> (except for submittable fields, where it need not be unique).
>
> So it looks a bit odd to introduce @name for a new element.
What you say is true for some uses of name="", but in the form API in
particular, name="" works pretty well, due to the "elements" object.
> > Consider what this would look like without the form.elements API:
> >
> > <form name="main">
> > Result: <output name="result"></output>
> > <script>
> > document.forms.main.elements.result.value = 'Hello World';
> > </script>
> > </form>
>
> With <output id="result"></output>, it would have
>
> document.getElementById('result').value = 'Hello World'
>
> and if jQuery is used (and more than half of the world uses it, or
> something similar), it would have
>
> $('#result') = 'Hello World'
>
> I would say that both ways are simpler than the property chain
> document.forms.main.elements.result.value and, moreover, a way that can
> be used to access any element, not just <output>.
I guess this is an area where opinions differ.
> > Well, more or less by definition, [if] <output> is appropriate for
> > something, it's more appropriate than <span> would be, since <span> is
> > more generic. <span> is like the "fall back" element, it has
> > essentially no semantics at all.
>
> That's a rather theoretical proposition. You say that <output> is for a
> result of a calculation or user agent and call this "semantics".
That's basically how that works, yes. :-)
> But how would that be a tangible benefit.
The main benefit is the one I describe above, the way it interacts with
the form elements API. The benefit of the semantics is the same as the
benefits of any semantics, mainly that it makes code maintenance easier,
makes it easier for new authors to enter a project and know what's going
on, etc.
> > I think the improvement of "o" relative to
> > "document.getElementById('o')" should be self-evident;
>
> If you intend to use plain "o" instead of a property chain, I'm afraid
> many people would regard it as poor programming practice. But anyway, if
> you do that, why not use "o" the same way, when id="o" has been used
> (for any element)?
I'm not sure what you mean. I think this might just be a difference of
opinion, though.
> > that libraries like jQuery feel the need to do exactly this kind of
> > simplification is exactly the kind of evidence we use when trying to
> > work out what needs simplifying.
>
> If the verbosity of document.getElementById(...) is really the problem,
> why solve it only for a new, rather specialized element?
It's not a new solution. We're just using an existing solution, the naming
of form controls, and applying to a new form-related element.
> And if it is a problem, it's really a scripting language issue.
I don't know that I would describe it as a big problem. It's just a
convenience issue, really.
> Introducing an entirely new element to a markup language looks like a
> wrong move.
Introducing new elements is definitely something we should be careful
about, but at the end of the day, that's how a language evolves.
> > > And anyone who does not like the length of document.getElementById()
> > > and does not want to load jQuery can write his own function for the
> > > purpose.
> >
> > It's hard to simulate the simplicity achieved by <output>, even with a
> > function.
>
> With just one simple function definition, you can use ...('o').value,
> where ... is a function identifier of your choice, instead of
> document.forms.main.elements.o.value or the risky o.value.
It's the "('o')" part (vs "o") that's the issue. But again, maybe this is
just a matter of personal preference. If you prefer string arguments to
direct member access, then obviously a solution that prefers direct member
access to string arguments isn't going to look better.
> > Adding one for output in forms seems to make sense, since doing the
> > same for input is already possible. Especially given the low cost of
> > doing this.
>
> Even for <input>, it is safer and common to use references based on @id
> rather than @name, partly for uniformity of access, partly for
> uniqueness: you wish to access a specific element, not an element that
> happens to have a particular @name value.
This doesn't appear to be true. The form.elements.name API is reliable,
uniform, and well-defined. It also has the advantage of special features
to support radio buttons, and so on.
> And the cost is not low: there is confusion about what the <output>
> element really is, whether we should use it, and (for many years) if we
> use it, how do we deal with old browsers that do not recognize it.
To be honest, the confusion about <output> is really minimal. We get very
few questions about it. The confusion caused e.g. by the W3C dropping
<hgroup> in their variant of HTML is far, far greater than any confusion
we've ever seen for <output>.
> > > > The output element represents the result of a calculation or user
> > > > action. That's what the spec says. I'm not sure what more you want
> > > > it to say.
> > >
> > > Well, what it really means. Is <output>4</output> OK just because I
> > > got 4 from calculating 2 + 2?
> >
> > Probably. It's hard to say for sure without more context. I mean, if
> > you're just writing a paragraph that starts like:
> >
> > <p>I bought two apples, then I bought two more, and now I have
> >
> > ...then I would say that <output> is probably unnecessary, but if you
> > find it useful to use here, it wouldn't be _wrong_ per se.
>
> I guess what is really meant is that <output> is for data produced by a
> client-side script.
Not necessarily client-side script. Consider the <output> example in the
spec, with the calculator:
<form onsubmit="return false" oninput="o.value = a.valueAsNumber + b.valueAsNumber">
<input name=a type=number step=any> +
<input name=b type=number step=any> =
<output name=o for="a b"></output>
</form>
One could imagine this being adjusted so that the addition operation is
actually done on the server. <output> would still be perfectly applicable,
the semantics are the same: the result of a calculation.
> And the added example is about data retrieved, by a client-side script,
> from a remote server. It might the result of some calculation (the
> example does not say that), or just data retrieved from a database -
> something that is not "result of a calculation or user action" in any
> normal sense.
The calculation in this case is that of finding prime numbers.
> > > So shouldn't "calculation" be clarified by saying that it is a
> > > calculation performed on the page, i.e. the result of executing some
> > > client-side script?
> >
> > Well, it could be the result of a calculation done by a remote host
> > based on user input, too. Or the result of a calculation done by
> > remote host C based on data from remote hosts A and B. The second
> > example in the <output> section shows an example of that.
>
> Only the word "primes" in some identifiers suggests that there is any
> calculation involved. And the data could well be just retrieved.
Fixed.
> The common factor seems to be that the <output> element value is written
> by a client-side script - how it gets the data is a different issue.
There's no semantic difference between something being added to the DOM
via script and being added via the parser. Having an element whose
semantic is "this was added by script" doesn't make any sense to me. What
purpose would it solve?
> > > This would probably cover "user action" too - it now looks odd,
> > > since the element content is not supposed to change directly due to
> > > user action, the way e.g. <input type=text> works.
> >
> > It can change directly based on user action (indeed the first example
> > of <output> in the <output> element's section does just that), it's
> > just not an actual input control itself.
>
> We have somewhat different meanings for "directly". I would say that an
> <input> element value can normally be directly changed by the user, e.g.
> by typing into a field, whereas e.g. copying, with a client-side script,
> input characters to another field means changing it indirectly.
I don't understand the difference. In both cases, physical impulse from
the user is being converted into moving bits on the display, where there's
a direct 1:1 relationship between the physical impulses and the bits.
Precisely what machine code runs to map the keyboard interrupt to changes
to the DOM and changes to layout or painting or whatever is rather
irrelevant. The term "directly" here just means that you hit a key, and
the relevant input appears, as opposed to the input being processed in
some less direct way (like adding the digits or working out a hash or
whatever).
I agree that if you think too hard about this it starts being a little
philosophical.
> It's a moot point in some cases, e.g. when you have buttons that add
> characters into an <input> field, perhaps as the only way of entering
> data there. But in at least one meaningful sense, a change of a
> control's value is indirect if it takes place via a client-side script,
> not via user's interaction with controls as implemented in a browser.
I think you view "client-side script" as more magical than I do. I guess
you mean "author-provided code" as opposed to "UA code", but what
difference does it really make what code is running?
> > > > The main practical gain is that it makes outputting data from
> > > > script in a form easier, since <output> is a listed
> > > > form-associated element.
> > >
> > > That statement, in some formulation, might be a useful addition to
> > > the description of <output>.
> >
> > I have made a conscious choice to not include rationales in the
> > specification, to keep the document manageable.
>
> People who read the specification will be puzzled by the <output>
> element when there is no "why".
There is now effectively a rationale, with the sentence I added earlier.
But in general, the examples are supposed to be sufficient here.
> They will probably not read a Wiki but check some online resources or
> maybe books until they find an explanation. So why not give them the
> reason you really mean?
Because it would easily double or triple the size of the spec if we
explained all the decisions in there, and I don't have the bandwidth to
maintain it.
If you'd like to maintain it, though, I'd be happy to merge it into the
spec in a way similar to how we merge caniuse.com data in, though.
> > Yeah, the <output for> attribute maybe should be dropped. It was
> > initially intended to allow UAs and ATs to let users jump to the
> > relevant controls from the output; in non-visual situations in
> > particular, this can in theory be quite helpful. If nobody implements
> > it, I imagine we'll drop it.
>
> I don't see how it would be helpful even in theory.
In theory, a user is going through the document, and gets to the part that
says "Total: $1200". The user wonders what contributed to this total, so
hits the "link to sources" key, and the AT jumps the user to the controls
that affect the output. The AT presumably makes some sort of audio cue to
let the user know this is possible.
In theory. Like I said, If nobody implements it, I imagine we'll drop it.
On Sat, 5 Apr 2014, Steve Faulkner wrote:
>
> Currently the implementation(s) of summary/details elements do not match
> the spec.
That happens a lot with new specs. :-)
> In the spec, the details element is interactive content; the summary is
> not, it's a summary, caption, or legend.
>
> In webkit/blink the summary element is the interactive element (when
> pressed it opens/closes the details element). This is good because it
> provides a large default hit region to activate the control.
>
> An issue with current implementations is that when the summary element
> includes other interactive elements (as it is allowed to), clicking on them
> results in the details element being opened/closed (although this can be
> overcome via scripting).
> The interactive part of the details element is the disclosure triangle,
> which is supposed to be an anonymous control in the shadow DOM.
>
> The <summary> itself is not interactive, so only the triangle provides
> the actionable control. the summary text which is effectively the label
> for control does not activate the control. There is no method provided
> to associate a label with the anonymous control that can (a) provide an
> increased hit region and (b) provide an explicitly associated label for
> the anonymous control.
The spec and the implementations are actually closer than this suggests,
because there's nothing in the spec that prevents the summary from
defaulting to the behaviour you describe.
On Tue, 8 Apr 2014, Steve Faulkner wrote:
>
> All controls are expected to have an accessible name and it is expected
> that the author is able to assign one. this is accessibility 101 across
> all platforms. Lack of an accessible name or a generic accessible name
> or an ambiguous accessible name causes issues for users.
The details element can be given a name using the regular ARIA attributes,
sure.
> What's the mechanism by which the anonymous control for details can be
> assigned an accessible name?
The disclosure triangle is just part of the <details> element. If you want
to give the details element an accessible name, you use the regular ARIA
mechanisms for doin so.
On Sun, 18 May 2014, Luis Farzati wrote:
>
> Sorry if this has been discussed already, but I wanted to ask you guys
> if you have considered making the list attribute available for selects.
On Sun, 18 May 2014, Anne van Kesteren wrote:
>
> I don't think so. What would the use case be?
On Sun, 18 May 2014, Luis Farzati wrote:
>
> As I see it, list is perfectly fine the way it was designed but it could
> be applied to select elements, thus enabling feeding options to a
> dropdown externally, thus enabling a way to reuse options in dropdowns
> (without redundant nodes).
Ah, ok. So your underlying request is "can <select> elements share a set
of options", basically?
> I am building long immigration forms for USCIS and, for example, a very
> common field is Country. It is asked several times even in the same page
> (for the address of birth, address of residence, address of your
> relative, etc...). Relative kind is another example.
>
> So I think it makes sense to have a single <datalist> and then have
>
> <select name="birth.country" list="countries"></select>
> <select name="residence.country" list="countries"></select>
We actually tried something like that in the old Web Forms 2.0 proposal,
IIRC. Unfortunately it didn't get much traction. At this point I would
probably say that the way to solve this would be to create a "country
selection" Web Component, and then use that. I'm not exactly sure how you
would hook that into form submission, but presumably that's possible.
On Tue, 3 Jun 2014, Daniel Morris wrote:
>
> With existing assistive technology such as screen readers, and more
> recently the pervasiveness of new technologies such as Siri and Google
> Now to name two examples, I have been thinking about the appropriateness
> and potential of having a way to represent the pronunciation of words on
> a web page.
>
> There is currently no other text-level semantic that I know of for
> pronunciation, but we have elements for abbreviation and definition.
>
> As an initial suggestion:
>
> <pronounce ipa=“ˈaɪpæd”>iPad</pronounce>
>
> (Where the `ipa` attribute is the pronunciation using the International
> Phonetic Alphabet.)
On Tue, 3 Jun 2014, Tab Atkins Jr. wrote:
>
> This is already theoretically addressed by <link rel=pronunciation>,
> linking to a well-defined pronunciation file format. Nobody implements
> that, but nobody implements anything new either, of course.
What we'd need to make progress on this would be implementor interest.
Without it, it's probably best not to add anything to the spec.
On Thu, 5 Jun 2014, Luis Farzati wrote:
>
> I'd like to propose that the select element could be shown either as a)
> a dropdown list (current UI), b) a list of checkboxes c) a list of radio
> buttons.
The spec allows that today, for browsers.
In theory, Web Components, probably in a later revision, will let you
override the default rendering of <select> to do this.
On Thu, 26 Jun 2014, Tim Marinin wrote:
>
> Most often use for tag <script> is to include external script through
> <script src="somecdn.example/jquery.js">, or alike. May be we could add
> rel="script" to <link> tag with same behaviour as <script> with src.
If we were designing from scratch, I agree, but at this point that's more
cost than value unfortuntely.
On Thu, 10 Jul 2014, Garrett Smith wrote:
>
> 1. Form `dirty` property. Set to false, initially. Set to true when the
> user has interacted with any of the form's controls to make them dirty.
What's the use case? Can you work around this by just catching 'input'
events on the <form>?
> 2. HTMLFormControl. Why is there no HTMLFormControl interface? I see
> HTMLFormControlsCollection but no HTMLFormControl. HTMLElement doesn't
> cover HTMLSelectElement. I see a 'listed' category. Why no interface
> defining HTMLFormControl?
What would the purpose of this interface be?
> 3. To determine if a form control is eligible for success (see below)
> `HTMLFormControl.isEnabled`
What's the use case?
Would an unchecked checkbox be considered "eligible" by this criteria?
> 4. To get the value of a form's enabled controls as a string:
> HTMLFormElement.serialize(type, callbackFunction). `type` can be "json"
> or "query".
What's the use case?
Note that FormData (see xhr.spec.whatwg.org) might already handle this to
some extenet.
> 5. Set the value of a form's controls using HTMLForm.revive(object[,
> metaReviver])
I'm not sure I follow what you're saying here. Can you elaborate?
> Disabling a fieldset disables its descendant controls but does not
> change their disabled property. Thus, a disabled fieldset's descendant
> controls won't succeed, however, its descendant controls' `disabled`
> property can be true.
Yeah, the "disabled" property just reflects the disabled="" attribute.
> From what I understand, the word "disabled" it appears in HTML5 is
> overloaded to describe the following three different things:
>
> 1) The form control's disabled `property` *
The spec prefers the term IDL attribute, but yes.
> 2) The form control's disabled attribute (content attribute) **
>
> 3) The form control's eligibility for success. ***
Right.
> I propose changing one of these -- the last -- to the positive sense --
> isEnabled, and exposing that in the DOM. Because it's not so useful to
> have a form whose disabled property is false but the form is "disabled"
> due to being a descendant of a disabled fieldset.
What's the use case?
Is it common enough that it's worth having a convenience API for it? (You
can always write a function to determine the state.)
On Fri, 11 Jul 2014, Garrett Smith wrote:
>
> In response to the need for a compelling use case, the situation is as
> Tobie pointed out: Serialize a form's successful controls as name/value
> JSON to the server, and vice versa: to revive the form with a server
> response.
That's not a use case, it's a solution. A use case is something like
"allow the user to indicate to the page that an e-mail should be sent", or
something. (That use case would motivate <a herf="mailto:..."> or <input
type=button> with a way to tell the server to send an e-mail.)
> Consider a private enterprise app with a form where the browser (1)
> sends that form's data over the wire without reloading the page, and (2)
> receives data from the server to populate form controls. In some places,
> there is a nice 1:1 mapping of a json property name:value pair to a form
> control name:value pair, but in other cases, it is necessary to have an
> adapter in both in the serialization of the form and in the repopulation
> of the form ("reviving"). For serialization, a jsonReplacer is a
> function that is used for replacing gathered form data, and a
> jsonReviver is a function used in repopulating form data from the
> server.
This seems like something that is relatively straight-forward to
implement. Why would we want the browsers to have this built-in?
> Form serialization requires determining the successful form controls.
> And to determine what successful controls are we have to look at HTML
> 4.01 and HTML5. Those specifications both state that disabled form
> controls are not successful. And the problems implicit in my initial
> post are (1) that "disabled" has a new, additional meaning in HTML 5
> which is not easy to understand and (2) once understood, it is harder
> yet to determine via the DOM. In other words, it's not easy to know if a
> form control is "disabled" in the new sense of the word, because of the
> FIELDSET disabled property.
It's not trivial, but it's not particularly hard, either. There's a clear
set of steps in the spec for constructing the form data set:
https://html.spec.whatwg.org/#constructing-form-data-set
As far as I can tell, it would be straight-forward for someone to
implement this in JS and thus turn the form into JSON.
On Tue, 22 Jul 2014, fantasai wrote:
> On 03/02/2008 03:02 PM, Ian Hickson wrote:
> > On Tue, 31 Jul 2007, Philip Taylor wrote:
> > >
> > > IE undocumentedly recognises some which nobody else does:
> > >
> > > aafs U+206D ACTIVATE ARABIC FORM SHAPING
> > > ass U+206B ACTIVATE SYMMETRIC SWAPPING
> > > iafs U+206C INHIBIT ARABIC FORM SHAPING
> > > iss U+206A INHIBIT SYMMETRIC SWAPPING
> > > lre U+202A LEFT-TO-RIGHT EMBEDDING
> > > lro U+202D LEFT-TO-RIGHT OVERRIDE
> > > nads U+206E NATIONAL DIGIT SHAPES
> > > nods U+206F NOMINAL DIGIT SHAPES
> > > pdf U+202C POP DIRECTIONAL FORMATTING
> > > rle U+202B RIGHT-TO-LEFT EMBEDDING
> > > rlo U+202E RIGHT-TO-LEFT OVERRIDE
> > > zwsp U+200B ZERO WIDTH SPACE
> > >
> > > (I believe that list is complete.)
> > >
> > > The first eleven were suggested on
> > > https://listserv.heanet.ie/cgi-bin/wa?A2=ind9605&L=html-wg&P=4579
> > > some time ago but don't seem to have gone very far (except into IE).
> > >
> > > I can see some legitimate users at
> > > <http://www.tasb.com/services/field/staff/index.aspx?print=true> and
> > > <http://www.pelesoft.co.il/> and maybe there's a few dozen or
> > > hundred more elsewhere (but I can't measure it easily). There's some
> > > in text-art at
> > > <http://yy28.60.kg/test/read.cgi/maido3/1096370177/l50> and quite a
> > > lot in weird places like
> > > <http://cheese.2ch.net/life/kako/1010/10103/1010391447.html> or
> > > <http://zerosen52.gozaru.jp/log/1093422333.html> that I don't
> > > understand but that seem to all be on 2channel (or copied from it).
> > > I've no idea how common they are in general.
> > >
> > > Are these used significantly on the web, or would they be considered
> > > highly useful if anyone knew they existed, or should HTML5 just
> > > ignore them?
> >
> > I'm very skeptical about introducing entities for the codes that are
> > redundant with dir="" and <bdo> (namely, lre, lro, pdf, rle, rlo).
>
> I agree 100% with this rationale.
>
> > I don't know enough about the others to have an educated opinion. I
> > can set up a search to examine the data in more detail.
>
> I don't know much about the others, but I can provide some info on ZWSP.
> It is (as specced) equivalent to <wbr>. Specifically, it
> * defines a word break (line-breaking opportunity)
> * thereby breaks Arabic joining
>
> For contrast:
> ZWSP - Breaks a word (and therefore also Arabic joining) with no visible
> space.
> ZWJ - Not a word break. Forces joining behavior.
> ZWNJ - Not a word break, but breaks joining.
>
> ZWJ and ZWNJ are primarily useful for Arabic and other shaped scripts.
> I'm not sure of the common uses for ZWJ, but ZWNJ is frequently used in
> Persian to visually separate grammatical prefixes from the rest of the
> word (without breaking the word or introducing extra space).
>
> ZWSP is more likely to be used in Thai and related scripts, to define
> word boundaries. Thai does not use spaces between words, so break
> opportunities need to either be marked with ZWSP or found with a
> dictionary. Even in the presence of automatic dictionary-breaking,
> however, there are ambiguous cases which will need ZWSP to show the
> correct break-point.
>
> There's further discussion about this in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13108 I've no comment
> on concerns about compatibility with XML, but I can say that I've typed
> &zwsp; multiple times expecting it to work and find it surprising that
> ‍ and ‌ work, but &zwsp; does not...
>From speaking to implementors, it seems that there is very little appetite
for adding yet more named character references, so unless there's a
compatibility need that is strong enough to make multiple vendors
implement this, I'm going to leave these out.
On Wed, 23 Jul 2014, Michael Gratton wrote:
>
> As the spec currently stands, use of <input type=number> is unsuitable
> for currency and other input that require a minimum number of decimal
> points displayed. When displaying decimal currency values, the typical
> convention is that a precision of two decimal points is used, regardless
> of numeric value. That is, one dollar is displayed as "1.00", not "1".
> However the latter is the result when using <input type=number> in
> implementations that follow the spec, such as Chrome and Firefox.
>
> Section "4.10.5.1.9 Number state (type=number)" currently states: "If
> the user agent provides a user interface for selecting a number, then
> the value must be set to the best representation of the number
> representing the user's selection as a floating-point number" -
> effectively by calling JavaScript's ToString on the number. This gives
> rise to the undesirable representation above.
That's the wire format. It says nothing about the rendering format.
The rendering format is something that should be controlled either from
CSS or from Web Components and its successors.
My recommendation would be to request a better default rendering format
from browser vendors, and request control over formatting of form elements
from the Web Components and CSS groups.
On Mon, 4 Aug 2014, Christoph Päper wrote:
>
> Imagine a text layout GUI made with HTML. It would probably feature a
> font size selection control. There are different ways to do such a
> thing:
>
> <input type=number min=0 id=value><!--unit implied-->
>
> <input type=text id=value pattern="\d+([.,]\d+)? *(pts?|px|mm)\.?">
>
> <input type=number min=0 id=value>
> <input type=text id=unit pattern="(pt|px|mm)">
>
> <input type=number min=0 id=value>
> <select id=unit><option>pt</option><option>px</option><option>mm</option></select>
>
> There are, of course, more possible units and one might want to supply a
> ‘datalist’ with suggested predefined values, e.g.
>
> <datalist id=TeXsizes11>
> <option value="6" label="tiny">
> <option value="8" label="script">
> <option value="9" label="note">
> <option value="10" label="small">
> <option value="11" label="normal">
> <option value="12" label="large">
> <option value="14" label="Large">
> <option value="17" label="LARGE">
> <option value="21" label="huge">
> <option value="25" label="Huge">
> </datalist>
>
> Most desktop word processor GUIs use something like option 2, by the
> way, some always expect points and hence only provide solution 1 or just
> a drop-down list of predefined values.
>
> It’s not possible, however, at least as far as I know, to strongly
> associate the two controls in options 3 and 4 (i.e. for number and unit)
> with each other, so UAs could employ a native widget for typed values.
Are there such native widgets in typical GUI toolkits?
> When the user changes the unit, such a widget could either keep the
> numeric value or convert it accordingly. This is what I’d like to
> propose, but am not sure yet how.
This seems like exactly the sort of thing that Web Components would be
good for.
On Fri, 10 Oct 2014, Ezequiel Garzón wrote:
>
> Greetings! I believe the current standards has an oversight in the
> current rules for omission of the p element's end tag:
>
> "A p element's end tag can be omitted if the p element is immediately
> followed by an address, article, aside, blockquote, div, dl, fieldset,
> footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu,
> nav, ol, p, pre, section, table, or ul, element, or if there is no more
> content in the parent element and the parent element is not an a
> element."
>
> Shouldn't the new figure element be in that list?
Fixed, thanks!
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 27 October 2014 20:41:59 UTC