4 ms·
Does anyone actually care about the header levels (h1, h2, h3 ..) when writing text? As far as I can tell, what you actually want is to denote a section and gi
by hsn915 5y ago
Does anyone actually care about the header levels (h1, h2, h3 ..) when writing text?
As far as I can tell, what you actually want is to denote a section and give it a header, and within the section you may want to denote sub sections.
Something like this:
@section {
@title: This is my section title
Text, paragraph, etc.
@section {
@title: Subsection Title
Text, text, text.
}
}
But I'm not aware of any markup language that lets you do this.
- qbasic_forever 5y agoHTML5 has <section> blocks for this kind of document structure: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se...
- hsn915 5y agoI meant more broadly, the header level number should be derived from its nesting level without you specifying it explicitly. This gives you more freedom to re-arrange (refactor?) the text without having to mass-edit header levels.
- psytrx 5y agoThis is what annoys me the most when developing web components. You never know which context your component might be used in, and your <hX> element might be just plain wrong. I prefer not using them and fall back to using <header> elements inside sections, but styling them globally makes it rather difficult and ugly to work with. What's other people's solution to this? Or am I just picky when it comes to semantics?
- qbasic_forever 5y agoIf it's super broken or critical, maybe a slot to let the user provide their desired header level would be an option? Or maybe even a simple prop would be enough. If your component is itself header-like, perhaps making 6 versions, fun-header-1, fun-header-2, etc. that are explicitly scoped to that level header would make sense too.
- dgb23 5y agoYou could define a recursion depth parameter for your component. Or a specific header level parameter. I tend to think of spitting out HTML as something with recursive context. The CSS grid and even flex layouts come to mind as well.
- zozbot234 5y agoHTML5 allows this, per the spec. Seems that it's not always implemented properly, though.
- chrismorgan 5y agoSpecifically, this is the document outline algorithm. But it’s not so much “not always implemented properly” as “not implemented at all”. No user agent has implemented it or seems likely to, and I don’t know of anything other than conformance checkers that implements it. https://github.com/whatwg/html/issues/83 https://github.com/whatwg/html/issues/83 shows a bit of the discussion that’s gone on; whether to remove it, simplify it drastically to the point that it’s actually sanely implementable, &c.
- defluct 5y agoYes, this has also been something I've missed from mostly all markup languages, but the renderer also has to make a distinction between paragraphs inside and outside of a section. To better illustrate: @section { @title: This is my section title Text, paragraph, etc. @section { @title: Subsection Title Text, text, text. } More text that belongs to the parent section. But how will the reader know that? Indentation? Blocks with background color maybe? }
- hsn915 5y agoIt could be a requirement that text paragraphs be preceeded by a title to disambiguate this situation.
- defluct 5y agoNo that is how the system works today. I would like, and have always wanted a way to disambiguate without creating a new title. There should be some sort of visual indicator that we are going up to the parent level without creating a sibling to the parent. title: ships p: ships travel on water p: they are like cars but on water title: motors p: ships have motors p: spin around p: very powerful p: ships can be used for many things title: fishing p: fish are in water, so the incentives are super-aligned
- account-5 5y agoThe only issue I see with this is infinite levels. Parsing this may become an attack vector. Might be my ignorance speaking though.
- badsectoracula 5y agoI've been hacking now and then on a document preprocessor that uses a similar syntax, e.g. this code @Section[name=quickstart]{@Title{Quickstart} @P{ The official documentation is very sparse, but as a quickstart here is what you need to do: } @List{ @Item{Create a fullscreen window to render into} @Item{Initialize the library with @FuncRef{S3DTK_InitLib}.} @Item{Create a renderer with @FuncRef{S3DTK_CreateRenderer}.} @Item{Create an IDirectDraw instance - DirectDraw is mainly used to manage video memory.} @Item{Setup exclusive and fullscreen cooperative level and set the video mode to 640x480x16bpp or whatever.} @Item{Obtain the base of the framebuffer (see below) to use for calculating surface offsets.} @Item{Create a primary surface with a secondary buffer attached to it to act as a swap chain.} @Item{Create two @TypeRef{TS3DTK_SURFACE} variables to hold info about the surfaces. S3D actually needs very little info about a surface: its size, pixel/texel format and the offset in video memory from the framebuffer. This bit is the trickiest one.} @Item{Optionally create a 16bit surface to hold a z buffer - again you need to do this via DirectDraw and @TypeRef{TS3DTK_SURFACE}.} } @P{ And that is about it. Beyond that it is mainly setting state and drawing triangles. In terms of memory management, S3D relies on DirectDraw to do the video memory allocation/etc so in general the process is allocating a DirectDraw surface and filling a @TypeRef{TS3DTK_SURFACE} variable with info about it. The S3D API itself does not actually know about DirectDraw, it is only used indirectly to obtain the memory offsets and to perform surface flipping. In theory it might be possible to allocate a big surface and chop it to smaller pieces with multiple @TypeRef{TS3DTK_SURFACE}s. } produces the list at the top of [0]. The main difference in the syntax is that instead of "@title: blah" you type "@title{blah}" because "blah" is just the content for the "title" node and the parser doesn't treat any nodes in a special way, it just creates a tree and then passes it to a script for doing whatever it wants to do (to produce the linked HTML document it is passed to a script that generates HTML in a variety of formats - e.g. single file, multiple files, using HTML5 elements or sticking to "basic" HTML that works in a bunch of primitive viewers, etc). The "Section" node above uses "P" but strictly speaking it isn't necessary as any text after the } will create text nodes for the parent node (in this case the "Section" node). I did it this way mainly for consistency, but a script could just use the node's own text (which is basically what nodes like "FuncRef", "TypeRef", etc are doing). (i do not have any releases for the processor yet since i'm still -slowly- tweaking it as i -very slowly- write various documents using it) [0] http://runtimeterror.com/tech/s3dtk/docs/s3dtk_quickstart.html http://runtimeterror.com/tech/s3dtk/docs/s3dtk_quickstart.ht...
- qw 5y agoThat was the intention of XHTML 2.0. Header levels would have been derived from the document structure. <section> <h>Hacker News/h> <section> <h>Guidelines</h> </section> <section> <h>FAQ</h> <section> <h>...</h> </section> </section> </section>
- adamrezich 5y agoman I miss xhtml
- john-doe 5y ago> Does anyone actually care about the header levels (h1, h2, h3 ..) when writing text? Anyone using a screen reader.
- lifeformed 5y agoBy "anyone" they mean anyone authoring the content. The nested sections can easily by parsed into the appropriate header level when publishing.