Giter VIP home page Giter VIP logo

Comments (8)

jgm avatar jgm commented on August 23, 2024

You could always nest the section in a div?

https://djot.net/playground/?text=%3A%3A%3A%0A%23+Heading%0A%0AParagraph%0A%3A%3A%3A%0A%0A%23%23+Heading+2%0A&mode=html&sourcepos=false

from djot.

chrisjsewell avatar chrisjsewell commented on August 23, 2024

Yeh, but ughh, I feel that doesn't seem very readable or user friendly

In the example, its not clear why its in a div, and seems more like a "hack" than a feature πŸ€”

from djot.

chrisjsewell avatar chrisjsewell commented on August 23, 2024

I guess its not the end of the world, if this is the "solution" 😬

But I do feel at least this aspect of the heading parsing should be better documented in https://htmlpreview.github.io/?https://github.com/jgm/djot/blob/master/doc/syntax.html#heading

I guess the logic is that headings add sections if they are a child of the doc or another section?

from djot.

jgm avatar jgm commented on August 23, 2024

I guess the logic is that headings add sections if they are a child of the doc or another section?

Yes. Agreed that the "section" behavior should be documented.

As for ugliness, I think it's no more ugly that {section=false} (though perhaps less explicit as to its purpose, at least for people who know English).

What's the real-world case that is motivating this?

from djot.

chrisjsewell avatar chrisjsewell commented on August 23, 2024

Yes. Agreed that the "section" behavior should be documented.

πŸ‘

As for ugliness, I think it's no more ugly that {section=false} (though perhaps less explicit as to its purpose, at least for people who know English).

No you are right actually, I should of never doubted you πŸ˜…

But yes documenting the section behaviour woulf be great thanks πŸ™

from djot.

Omikhleia avatar Omikhleia commented on August 23, 2024

It's perhaps not only a documentation issue. To me, it might also lead to inconsistencies in interpretation, as attributes and ids are on the section node when present, not the header:

{ .red }
# Chap1

Lorem

{ .twocolumn }
:::
{ .blue }
# Chap2

Ipsum
:::
doc
  section class="red" id="Chap1"
    heading level=1
      str text="Chap1"
    para
      str text="Lorem"
    div class="twocolumn"
      heading level=1 class="blue" id="Chap2"
        str text="Chap2"
      para
        str text="Ipsum"

Which content is supposed to be "red", and "blue" ? The whole section (including all child nodes) or just the header?
Where are links supposed to be applied (e.g. if chapters introduced a page break to start on an odd page in print), where the section starts or where the actual header ends up?
Is the expected sectioning really respected in the above?

EDIT:

as attributes and ids are on the section node when present, not the header:

BTW if I am not mistaken, djot.lua (at least at one point) differs from djot.js / the online playground here - having the id on the section node, but not the other attributes.

from djot.

jgm avatar jgm commented on August 23, 2024

This would be less confusing if there were just one AST element, Section, with a field for a title. Of course, this would be rendered in HTML as a <hN> element embedded in a <section>. But then, it would be clearer conceptually why all the attributes go on the section, and it is impossible to put them on the heading.

Which content is supposed to be "red", and "blue" ? The whole section (including all child nodes) or just the header?

In HTML output at least, you can choose by using appropriate CSS rules.

from djot.

bitfehler avatar bitfehler commented on August 23, 2024

Sorry in case this is not entirely the right place for this question, but I found this issue trying to figure out the intended behavior of block attributes added to headings. Now, the last comment says (emphasis mine):

But then, it would be clearer conceptually why all the attributes go on the section, and it is impossible to put them on the heading.

This seems to be the answer I was looking for, but I initially played with the playground, and was a little surprised by this example:

doc
  section
    heading level=1 foo="bar"
      str text="heading"
    para
      str text="text"

Somewhat unexpectedly, all attributes are assigned to the section instead if, and only if, one of them is an id.

Is that an implementation issue? Is it possible to describe the intended behavior in a sentence or two? I am not so much interested in the workarounds, but curious about the consistency here, like "if a heading generates a section, all attributes should be assigned to the section"? Thanks for Djot btw, and thanks in advance for any guidance πŸ™‚

from djot.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.