While going through an XBRL instance file, I saw an element. But that element is not present in the corresponding 'extended link' in the definition link base in the taxonomy(though it is present in the xsd). There is another similarly-named element in the def linkbase in that extended link, but it's not used in the xbrl.
I usually compare the financial report and the definition linkbase (section by section) to identify the XBRL elements to be used. Am I following the right approach? How can I identify which XBRL elements to use for a particular section of a financial report?
There's nothing in the the spec that says what elements can and can't be used. The closest you'd get is a requires-element relationship that describes 'if x is present than y must also be present' semantics.
If an element exists in the discovered schemas, then it's valid in the instance.
Related
I was searching for ::before/::after pseudo-elements and found this description ...
1.1. Accessibility of Generated Content
Generated content should be searchable, selectable, and available to assistive technologies. The content property applies to speech and generated content must be rendered for speech output. [CSS3-SPEECH]
In another place ...
Since they are not restricted to fitting into the document tree, they can be used to select and style portions of the document that do not necessarily map to the document’s tree structure.
and
Like pseudo-classes pseudo-elements do not appear in or modify the document source or document tree. Accordingly, they also do not affect the interpretation of structural pseudo-classes or other selectors pertaining to their originating element or its tree.
Is it consistent to ensure "searchable, selectable, and available" for something that is not mapped on the document and does not exist? If it is not in the document tree, it should not be selectable.
If the content has already been discussed (or concluded) in the CSSWG, I would you like tell me that where the topic was discussed, and how to achieve "searchable, selectable, and available" consistent with current specifications.
Or, if you have a better place to discuss this, please comment.
#Alohci 's comments...
There's a difference between the current state of the art, and what is possible. "Searchable and selectable" are probably limited to the document tree at the current time, but there's no fundamental reason why that needs to be the case. That's kind of the point of the phrase that you quote at the start of your question - that those actions need to be moved to be actions on the render tree instead. But that's a big change and hasn't happened yet.
On the other hand, it's not that radical. for instance you can't select or search parts of the document tree that are display:none, so browsers already take some account of the render tree.
If you have an answer, please post in addition to this for future reference.
It seems the only real difference between the figure and aside elements, is that a figure is "referenced" by the main flow, where as an aside is not.
What exactly does reference mean in this context?
For example if I have a figure image of a mountain. Does it mean I need to point out that exact figure of the mountain or does it mean I could be talking about a mountain. How specific does a "reference" need to be for its proper use? Also if it needs to be referenced by the main flow does that mean it needs to be something the entire page is about and not just an article of it?
<figure>
<img src="mountainReiner.jpg">
<figcaption><p>mount reiner</p></figcaption>
</figure>
<p> paragraph talking about mountain reiner</p>
2017-07-18 update
The HTML spec was updated[❄︎][❆] to clarify what’s meant by referenced as far as HTML elements.
The word referenced in the figure element section and also in other sections is now a link to https://html.spec.whatwg.org/multipage/dom.html#referenced which reads:
Elements can be referenced (referred to) in some way, either explicitly or implicitly. One way that an element in the DOM can be explicitly referenced is by giving an id attribute to the element, and then creating a hyperlink with that id attribute's value as the fragment for the hyperlink's href attribute value. Hyperlinks are not necessary for a reference, however; any manner of referring to the element in question will suffice.
And there’s a detailed example following that text.
2017-07-13 original answer
What exactly does reference mean in this context?
It comes from the fact that in print publishing, figures are illustrations that are titled and numbered so you can cite them (reference them) by number+title easily in some any part of a publication.
For example, see how-to-use-figures style guides such as the following:
MLA Tables, Figures, and Examples — https://owl.english.purdue.edu/owl/resource/747/14/
Each illustration must include a label, a number, a caption and/or source information.
APA Tables and Figures — https://owl.english.purdue.edu/owl/resource/560/20/
For figures, make sure to include the figure number and a title with a legend and caption.
MLA Citation Guide (8th Edition): Images, Charts, Graphs, Maps & Tables — https://columbiacollege-ca.libguides.com/mla/images
Each figure should be assigned a figure number, starting with number 1 for the first figure used in the assignment.
In Web documents, you can just put an id attribute on the figcaption elements that provide the title for each figure, and then use a-element hyperlinks to reference those titles, so numbers for figures aren’t strictly necessary. But many Web documents use numbered figures anyway.
Does it mean I need to point out that exact figure of the mountain or does it mean I could be talking about a mountain.
It means, give figures a figcaption with a title+id that lets you refer to it elsewhere in the doc.
How specific does a "reference" need to be for its proper use?
It can (should) be exact—a hyperlink pointing to a unique id.
Even if the figure is unnumbered and has the same title as another figure in the same document, if it has a unique id attribute, you can refer to it specifically/exactly by hyperlinking to that id.
Also if it needs to be referenced by the main flow does that mean it needs to be something the entire page is about and not just an article of it?
No, the HTML spec at least imposes no special requirements like that.
For the record here, the relevant language from the HTML spec is this:
The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.
https://html.spec.whatwg.org/multipage/grouping-content.html#the-figure-element
Reference means the subject matter or what your web page is about. If your web page is about Hiking(the referent), the figure of the mountain is there to reference the theme of hiking.
Another version is:
Aside is information that is not related directly to the main content. (Generally not assisting directly in the main content. (such as car parts for the Hiking Page)
Figure may be used most widely in documents to illuminate the main themes of the document or to assist proving the main theme.
I was reading James Donnelly's answer to "Is there a standardized (Meta?) Tag for the Date of a Website?". At the end he writes:
I don't believe Hangy's answer of dc.date (now dcterms.date) would be relevant here as, as far as I'm lead to believe, the date of this is the date associated with the resource. For example, if the resource was a discussion about the Battle of Hastings in 1066, the dcterms.date could be set to 1066. The same could also be said for icas.datetime.
The definition of dcterms.date is "A point or period of time associated with an event in the lifecycle of the resource." I think the question is whether this "event in the lifecycle of the resource" means an event discussed within the resource, or an event pertaining to the resource itself.
Looking around, I found an example of the use of dcterms:date:
ex:myManuscript dcterms:date "1633"^^dcterms:W3CDTF .
The use of 1633 in the example leads me to believe Donnelly's interpretation is right (especially since the other examples on the same page use dates in the 2000s).
However, reading this post, I also discovered that Dublin Core has a dumb-down principle. Quoting from the post:
The solution to the paucity of Dublin Core elements was this thing called “qualified Dublin Core” (although that term doesn’t seem to be used much any more), in which the fifteen core elements are qualified to make them more specific — for example, dateAccepted, dateAvailable and dateCopyrighted are refinements of the core element date. According to the Dublin Core’s own dumb down principle, “a client should be able to ignore any qualifier and use the value as if it were unqualified […] Qualification is therefore supposed only to refine, not extend the semantic scope of an Element.”
This leads me to believe that Donnelly's interpretation is incorrect.
So my question is: What is the correct interpretation of Dublin Core's definition of dcterms.date?
There are two ways how the DCMI Metadata Term date can be used in HTML5 documents:
in meta-name elements (in the head element), because it’s registered as MetaExtension:
dcterms.date
in URI-based structured data syntaxes (typically RDF serializations like RDFa or JSON-LD, but possibly also Microdata):
http://purl.org/dc/terms/date (with the RDFa Initial Context: dc:date or dcterms:date)
In the latter case, you can differentiate if you are talking about the document or about the thing the document represents. You just have to give the thing a URI (see more details in my answer).
In the former case, HTML5 doesn’t allow this differentiation. The HTML5 specification defines that a meta element with the name attribute represents "document-level metadata"; "it sets document metadata". So unless it’s defined otherwise for the keyword dcterms.date (which doesn’t seem to be the case), the date should be associated with the document, not the thing.
I'm considering writing code which produces an HTML tag that could have duplicate attributes, like this:
<div data-foo="bar" class="some-class" data-foo="baz">
Is this legal HTML? Does one of the data-foo-values take precendence over the other? Can I count on semi-modern browsers (IE >= 9) to parse it without choking?
Or am I about to do something really stupid here?
It is not valid to have the same attribute name twice in an element. The authoritative references for this are somewhat complicated, as old HTML versions were nominally based on SGML and the restriction is implied by a normative reference to the SGML standard. In HTML5 PR, section 8.1.2.3 Attributes explicitly says: “There must never be two or more attributes on the same start tag whose names are an ASCII case-insensitive match for each other.”
What happens in practice is that the latter attribute is ignored. Well, future browsers might do otherwise. In the DOM, attributes appear as properties of the element node as well as in the attributes object, so there would be no natural way to store two values.
It's not technically valid, but every browser will ignore duplicate attributes in HTML documents and use the first value (data-foo="bar" in your case).
Using the same attribute name twice in a tag is considered an internal parse error. It would cause your document to fail validation, if that's something you're worried about. However, it's important to understand that HTML 5 defines an expected result even for cases where you have a "parse error". The parser is allowed to stop when it encounters an error, but if it chooses not to stop it must produce a specific result described in the specification. In practice, no browsers choose to stop when encountering errors in HTML documents (XML/XHTML is a different matter), so all modern browsers will handle this case successfully and consistently.
The WHATWG HTML specification describes this case in section 12.2.4.33 "Attribute name state":
When the user agent leaves the attribute name state (and before emitting the tag token, if appropriate), the complete attribute's name must be compared to the other attributes on the same token; if there is already an attribute on the token with the exact same name, then this is a parse error and the new attribute must be dropped, along with the value that gets associated with it (if any).
See also its description of "parse error" from the opening of section 12.2 "Parsing HTML documents":
Certain points in the parsing algorithm are said to be parse errors. The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.
I wanted to add a comment to the excellent accepted answer, but my reputation is not high enough.
I wanted to add it is important to consider how your code gets compiled.
For example, Angular removes prior duplicate (non-angular) class attributes and only keeps the last one.
Note: Angular also modifies the value of the class attribute with ngClass and any [class.class-name] attributes.
This is also something you can use linter for.
See htmlhint (attr-no-duplication) or htmllint (attr-no-dup).
As far as I understand, the id attribute is used as a unique identifier for some tag in the entire document, while name is used as an identifier (not necessarily unique in the document) that is sent with some data to the server.
However, using the element inspector in pages from the MDN (take this as an example), I noticed that all the article's h1..h6 tags that are present in the navigation tree have name attributes, and that they are identical to their respective tag's ids. In this case, what is the usage of such attributes? Are they used to build the navigation tree?
Most likely it's used for bookmark anchors to jump to a specific part of the page. In ye olden days, you would use the name attribute to target the element, today however you use the ID. So it's probably just a holdover for backwards compatibility.
If you check out https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#Clicking_and_focus, you'll see the explanation:
name (HTML 4 only, Obsolete since HTML5) This attribute is required in
an anchor defining a target location within a page. A value for name
is similar to a value for the id core attribute and should be an
alphanumeric identifier unique to the document. Under the HTML 4.01
specification, id and name both can be used with the <a> element as
long as they have identical values. Usage note: This attribute is
obsolete in HTML5, use global attribute id instead.
The name attribute is allowed in various elements and has partly different meanings in them. On the page linked to in the question, it is used in heading elements, e.g.
<h2 id="JavaScript_Review" name="JavaScript_Review">JavaScript review</h2>
Such usage is not valid in any HTML version, and the name attribute has no effect in such elements. The construct is probably generated by some authoring software that has been coded or configured oddly.
To be exact, the attribute (like unknown attributes in general) is not completely ignored. It is stored in the DOM, in the attributes object of the element node (but not as name property of the node, as it would be if it were a defined attribute). This means that it could be used in scripting and in styling.